Open jmstacey opened 7 years ago
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.
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.
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. 😄
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.
Would be very useful if there was an out of the box connector to Redux DevTools extension. Integrated Time travel debugging would be awesome.