Twitter | Search | |
Dan Abramov
Working on . Co-author of Redux and Create React App. Building tools for humans.
49,888
Tweets
815
Following
124,834
Followers
Tweets
Dan Abramov 5h
Replying to @dan_abramov
You can’t fix what you can’t see.
Reply Retweet Like
Dan Abramov 5h
What state is the biggest source of bugs? The one that’s in your head.
Reply Retweet Like
Dan Abramov 7h
Replying to @joshduck
Maybe if you shake long enough
Reply Retweet Like
Dan Abramov 8h
With immutability and top-down data flow
Reply Retweet Like
Dan Abramov 8h
Depends on the kind of group. Some are like for announcements (as you describe), some are for discussion, some are random shitposting
Reply Retweet Like
Dan Abramov 8h
I think gDSFP is called _more_ often than render because it's called even before sCU.
Reply Retweet Like
Dan Abramov 8h
You can test it on 😅
Reply Retweet Like
Dan Abramov 8h
i.e. there's nothing gDSFP gives you here that helps with not-easily-comparable stuff. You have this problem in both cases, except with gDSFP you also have to write ugly code
Reply Retweet Like
Dan Abramov 8h
I don't see why gDSFP would be easier than memoization with custom prev/next comparison in this case
Reply Retweet Like
Dan Abramov 9h
Replying to @skippykawakami @swyx
It might also mean it shouldn't have any styling, and the actual rendering should be driven by a render prop API. Like Downshift.
Reply Retweet Like
Dan Abramov 10h
Replying to @chemitaxis
Search for “2.x roadmap” in the issue tracker and you’ll find it
Reply Retweet Like
Dan Abramov 10h
Replying to @kristoferbaxter
Sure
Reply Retweet Like
Dan Abramov 11h
Replying to @kristoferbaxter
Also happy to chat and answer specific questions
Reply Retweet Like
Dan Abramov 11h
Replying to @kristoferbaxter
There is a mix of things here (don’t miss further comments)
Reply Retweet Like
Dan Abramov 11h
Replying to @swyx
People start passing different classNames to a component to override some styling. Eventually the team that wrote the component is unable to make any changes to its style because every change breaks some callsite. So we learned to tightly control props, and discourage overrides.
Reply Retweet Like
Dan Abramov 11h
Replying to @swyx @sebmarkbage
Design Principles page in our docs is about React itself, not design principles of components. :-)
Reply Retweet Like
Dan Abramov 12h
Replying to @swyx
“Unpredictable edge case” with some prop combination also isn’t a styling specific issue. You could have the same problem with props you don’t use for styling. Which also points to the real problem being bad prop API design.
Reply Retweet Like
Dan Abramov 12h
Replying to @swyx
Interesting, maybe the prop API was just badly designed? At FB I’ve usually seen the opposite: in the longer term component libraries that allow customization (e.g. className prop) are the ones that slowly rot because it becomes impossible to modify without breaking
Reply Retweet Like
Dan Abramov 12h
Replying to @sebinsua
Exactly
Reply Retweet Like
Dan Abramov 12h
Replying to @swyx
The alternative to “breaking API changes” is that you still break things, but the API is the same so you don’t know about the breakage
Reply Retweet Like