Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redux DevTools Connector #14

Open
jmstacey opened this issue May 21, 2017 · 4 comments
Open

Redux DevTools Connector #14

jmstacey opened this issue May 21, 2017 · 4 comments

Comments

@jmstacey
Copy link

Would be very useful if there was an out of the box connector to Redux DevTools extension. Integrated Time travel debugging would be awesome.

@jgaskins
Copy link
Member

I like the idea of connecting to the Redux extension, but I think the difference between JS and Ruby objects would make it hard to read a lot of the time. For example, a Ruby hash would show up as something like this:

{
  $$id: 1234, // object_id
  $$keys: ['a', 'b'],
  $$map: {},
  $$smap: {
    a: 1,
    b: 2,
  },
  $$none: { $$id: 4 }, // This is kinda what nil looks like
  $$proc: { $$id: 4 },
}

… which is kinda gross. Instead, I wrote GrandCentral::DevTools, which should get you part of the way there. :-) I usually use this TimeTravel component in Clearwater apps. I might add it to that gem at some point.

@jmstacey
Copy link
Author

Good points. I hadn't thought about the connector not using source maps.

My thinking for the Redux tooling was mainly to provide a framework agnostic option for GrandCentral. I'm using Inesita rather than clearwater, so GrandCentral::DevTools would need to be rewritten to get up and running there.

@jgaskins
Copy link
Member

It should work regardless of whichever rendering framework you're using. It uses Clearwater to render, but it should be able to live alongside Inesita or Hyperloop or any of the others. If not, feel free to open an issue on that repo. 😄

@jgaskins
Copy link
Member

Also, it's not really about source maps, but about the structure of the objects themselves. Redux expects your state to use POJOs, which Ruby objects aren't, so the Redux dev tools aren't going to show Ruby objects as we see them, but how JS sees them. A lot of the time that wouldn't be terrible since I imagine most Ruby objects would look like POJOs with an $$id property, but as soon as you introduce a hash, for example, it'd get weird real quick.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants