Back when two-way binding was popular computed properties seems like another confusing layer
-
-
Replying to @jlongster @wycats
#3 would be better if cWRP had a more reduce-y API where you return a value. Then it would be more obvious how to compose it.
3 replies 0 retweets 4 likes -
Replying to @dan_abramov @jlongster
It's nicer to pull values when you need them than to reduce eagerly into one value, I think.
2 replies 0 retweets 2 likes -
Replying to @wycats @dan_abramov
At this point I think the most important thing is consistency: however you do it all of the app works that way (mixing them = worst of both)
1 reply 0 retweets 1 like -
Wait I thought cWRP *just* to help interop w/ 3rd party, non-react utilities? Isn't manually updating state from props in cWRP anti-pattern?
2 replies 0 retweets 0 likes -
I don't think so. If you use `setState`, that depends on props, you have to. Forbidding that makes apps even uglier imho
1 reply 0 retweets 1 like -
Updating state based on props (not very common but happens) is the only supported use case for cWRP
1 reply 0 retweets 9 likes -
But shouldn't that state be derived and pulled in render()?
2 replies 0 retweets 2 likes -
Not if it depends on both current and previous props/state. cWRP lets you handle those cases. If you already have all data, do it in render.
2 replies 0 retweets 3 likes -
Replying to @dan_abramov @wycats and
Or cases like "reset dropdown selection if input items have changed". Too late in render.
1 reply 0 retweets 3 likes
You just have to save it off last time it was used. No big deal (very Reactish I think)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.