Thanks for open sourcing your library. Mostly I write tree-helper functions on a project base, but would definitly be open to try this library next time.
Just skimmed through the code, here are some ideas/suggestions:
- You already have this on your TODO, but being able to use other property-names besides 'children', 'id' etc. would be cool. For example, often the term 'items' is used instead of 'children'.
- Often I need to have additional information about the node in the iterate function. For example, it could be quite useful to have access to the parentNode, the siblings or know the current depth.
- Since this is more like a small helper library, developers will look at the bundle size in order to decide if it's worth pulling this into a frontend project. You could reduce the size by not using lodash for example. I also don't think it's really necessary to have baked in currying, developers can add that, if they need it.
Thanks for this library!
One suggestion: Maybe you could state in the README that this library is more like an additional layer of protection. Because some developers may think that they don't need todo any additional checking of the input. But of course, even with this library installed, you shouldn't do stuff like `SELECT * FROM foo WHERE bar=${req.query.baz}`.
Can't wait to use this :)
After I used redux in a couple of projects I realized that it was actually overkill for most of the stuff I was doing.
So in the last two projects I decided to move the state into a Higher order Component instead. That turned out to work very well, even for a medium sized project. The nice thing is that I now can probably pull in freactal easily in those projects. Guess the approach of freactal should also scale quite well.
I agree with you that it may not make that much sense to use through2.
Generally I don't really mind pulling in small dependencies, even if they make stuff only a bit nicer. As long as the dependencies are easy replaceable and their code is understandable.
No Problem. sources.lifecycle sounds like a nice idea!
So the "Rx.Observable.interval(1000)" in the example gets called on componentWillMount at the moment, correct?