Consider rewriting with `redux-store-element`

[lastmjs]

I don't remember, but I'm sure I was inspired by your article when I was looking for Redux solutions for Polymer. I think your idea of using a custom element is the closest to what I was looking for, but it wasn't packaged nicely like I needed it, and there were a few things I would have changed. So I built my own, and I think it captures what you are trying to do and packages it up into a consumable custom element. It takes care of the singleton problem, and handles dispatching through data binding, and state updates through custom events that components listen to. I would like to see if you might consider rewriting the example and article using the element: https://github.com/lastmjs/redux-store-element

And if you don't have time, but think it would be a good idea, I could do it and make a pull request. Thanks for considering, and thanks for pioneering this.

[scaljeri]

Hi Jordan

That is really good work! I don't think however, rewriting my article is necessary at all, better would be to write a new one (say part 2 and I can link to it in my article, no problem). You could rewrite the demo app using your library too and it would be nice to compare!

One thing though, I noticed in your documentation that a component can directly access the state object, but I think (and please ignore all this if I'm wrong) a component should receive pieces of the state via its parent. Meaning you don't need the on-statechange event.

And one last thing, the listenersToAdd variable is defined global and private, but (and I haven't used typescript yet) is the private variable used at all ?

Cheers

[lastmjs]

Thanks! Yes, writing a new one sounds good. It might be a while before I have time, but I'll let you know when I get to it. As for the state, I think it is cumbersome to have to hook up a state property for every element in the hierarchy. In a larger application, some elements might not need the state, but if any of their children need the state you would have to attach the state property to the parents. Using a function that receives changes allows any component to grab the state whenever needed, without relying on any other components to get that state. That's how I used to so it in Angular, and I guess that's my opinion on it. As for the private listenersToAdd variable, it looks like that's never actually used...it's leftover from trying to do something earlier, I should take it out. Thanks!

[scaljeri]

It is never a good idea to hook up a component directly to the state or $rootScope. If you do that you create a tight relation between your state and component. If you pass only the required info to an element you can for example also use that element somewhere else on a different part of the state. Checkout this style-guide, especially this part. Cheers

[lastmjs]

You can still have stateless and stateful components like the style guide explains. The stateful components are the ones listening to state changes. They grab whatever piece of the state they need, and then can pass pieces of the state on to stateless child components. I believe one might need many stateful components in various places in the application, which is why it is desirable to be able to grab the entire state whenever desired. How redux-store-element does it is how I've seen it done by ng-redux.