Twitter | Search | |
:party-corgi:
If you find yourself writing a lot of `renderThing` methods on classes to split up your React render method, what you probably want to do is pull that area out into its own component because a render*() function effectively means theres enough complexity to be worth breaking down
Reply Retweet Like More
:party-corgi: Jun 6
Replying to @chrisbiscardi
Most (if not all) > 500 line components I've seen have many render* functions to abstract areas of render(). Pay attention when this happens and split the code out into its own file. render* functions tend to use a lot of "side-pull" props/state rather than direct usage.
Reply Retweet Like
:party-corgi: Jun 6
Replying to @chrisbiscardi
accessing this.props/this.state, etc in a render* function obscures it from view in the component's render(), making it harder to know what's going on (ex: you now have to traverse the file to find out if renderThing is using prop a)
Reply Retweet Like
John Detlefs Jun 6
Replying to @chrisbiscardi
Urgh, time to add a trello card.
Reply Retweet Like
Evan Jacobs Jun 6
Replying to @chrisbiscardi
Ehhh but then you get into the situation of ample prop passing. I don't think thicc components are necessarily a bad thing as long as they are well-organized and documented.
Reply Retweet Like
:party-corgi: Jun 6
Replying to @probablyup
you're already in that situation though. Either the app is small enough that it doesn't matter or big enough that there are plenty of other solutions that should be used for getting props to deeply nested components (GraphQL, reselect/redux, etc).
Reply Retweet Like
Corey Light Jun 7
Replying to @chrisbiscardi
I think about this a lot. I write components all the time with several render methods. I think about splitting them out but I usually don't because they will only be used once. I guess it's nice either way because it's pretty easy to rework as needed?
Reply Retweet Like
John Otander Jun 7
Replying to @chrisbiscardi
I've been meaning to write a post about this very topic because I see this pattern in apps a lot. Now I can just link your tweet instead because you've summarized it very well. <3
Reply Retweet Like
Hugo Di Francesco Jun 7
Replying to @chrisbiscardi @mxstbr
Adding a functional component in the same JS file is easy enough, if anyone else ends up needing, separate to its own file/module. One of the cool things that can't be done with Vue's single file components.
Reply Retweet Like
Kristie Howard Jun 7
Replying to @chrisbiscardi
I love this approach since it lets you build super small components and unit test them thoroughly, which has definitely improved both my style and code quality. I've tried to keep every component file under 300 lines (idk where i got that from but it's worked so far)
Reply Retweet Like
Brent Jackson Jun 7
Replying to @4lpine @chrisbiscardi
I still wanna read your article :)
Reply Retweet Like
John Otander Jun 7
Replying to @jxnblk @chrisbiscardi
Maybe someday : )
Reply Retweet Like
Manuel Bieh 🐝 Jun 7
Ha! That’s what I preaching so often
Reply Retweet Like
:party-corgi: Jun 7
Replying to @coreyalight
yeah, it's more about code organization than about re-use patterns. Some reusable patterns will fall out, but it's more about reducing the complexity to be able to focus on a single encapsulated thing at a time. It's easier to delete a file than multiple things inside a file.
Reply Retweet Like
:party-corgi: Jun 7
IMO there's more cognitive overhead in one file doing many things than in many files doing one thing each. A single component per file, like in the component folder pattern, makes it easier to refactor and delete no-longer-used code --
Reply Retweet Like
:party-corgi: Jun 7
It's easier to delete a whole file than multiple pieces of code inside of a file. At this point, my files on disk usually look similar to the react tree in devtools. Higher reusable components are handled via a multi-package repo setup.
Reply Retweet Like
:party-corgi: Jun 7
Replying to @4lpine
<3 I'd still read you post :)
Reply Retweet Like
:party-corgi: Jun 7
Replying to @kristiehow
That's funny because I also do 300 and don't know where exactly I got it from.
Reply Retweet Like
Sandro Manke (闪山) Jun 7
303. definitely 303!
Reply Retweet Like
Hugo Di Francesco Jun 7
I agree with both points of view, throwaway projects I prefer tons of functional components (maybe not all in their own file) rather than a class with renderX
Reply Retweet Like