nuclear-js-react-addons
nuclear-js-react-addons copied to clipboard
Comments on 0.3.0
@jordangarcia I'm curious as to why you made some of the decisions on 0.3.0
?
- why is
Provider
only a container element, I was assuming you were doing it because Babel 6 doesn't support decorators yet but noticedconnect
is still a decorator (assuming your decision is related to this https://github.com/rackt/react-redux/issues/66?). Also, kind of a bummer you can no longer pass additionalcontext
as this was useful in our current apps, now would manually have to setup that context. - why does
connect
setupreactor.observe
incomponentWillMount
. This potentially "solves" a lot of data binding issues I was having that I discussed with @Sinewyk becausecomponentDidMount
gets called from the inside out, so when binding initial state from actions incomponentDidMount
I would have to move this one level up abovenuclearComponent
to emit the Action. Seems easier this way but not very efficient ifcomponentWillMount
happens on both theclient
andserver
, seems pointless to setupreactor.observe
on the server? - why is the anonymous function inside
connect
being called again incomponentWillReceiveProps
andreactor.observe
being setup again here? Seems redundant? Previously this logic happened incomponentDidMount
- why is
redux
inpeerDependencies and not
nuclear-js` is there something going on I don't know about :-P?
cc: @jordangarcia
I think this repo is maintained by @Sinewyk ?
Kind of was. But I was not aware of the 0.3.0 so I can't answer this ^^.