3 ms·

Atrocious advice, I hope I never have to work in a codebase that follows these practices

by activitypea 5y ago

willio58 5y ago
Specifically what do you not like? Some of it seems iffy to me but some of it also seems obvious e.g. “use components”.
- purplerabbit 5y ago
  I find almost every section to be extremely distasteful. for instance, points 2 and 3 basically suggest throwing YAGNI out the window in favor of premature abstraction. Combine it with the highly-decoupled style in point 1, and you have a nice spaghetti recipe. I could keep going, but it looks like everyone is piling on this poor guy already.
  - activitypea 5y ago
    <3
- activitypea 5y ago
  I don't think there's a single paragraph in the article I agree with. In another comment, I picked on the parts that are the easiest to criticize in a shortish comment. The whole article screams bad OOP-style cargo cult programming, which I found particularly annoying :)
- eliseumds 5y ago
  It might be obvious to you. Hiding concrete implementations behind an elegant, easy-to-use interface, is not something we see every day. I've noticed countless codebases importing HTTP clients globally, mocking a ton of modules for testing, imperatively translating messages and so on. Wrapping implementations with components/hooks allows you to future-proof your application in case you need, for ex, to access some context data, to develop for a new environment (mobile, desktop), or for easier testing as already mentioned, including snapshots. I specially like that the author talks about wrapping third-party libraries. Another benefit of components is lifecycle. Imagine a "RelativeTime" component; you could have called library functions directly to render "20s ago", but by making it a component you could tell it to update periodically. Cool stuff. Now, I understand that having such granular components can lead to some performance overhead if you're working on a massive application. If only there was an easy way to do AST transformations that would hoist small stateless components/hooks. Damn, AST transformations could even hoist stateful ones! I'll keep dreaming about it :) In regards to examples such as `Fetch`, `UserRead` and `EntityActionDelete` from the post, I'm kinda on the fence because, at the same time they are uglier than hooks, they're also more performant because updates would only re-render itself and its children, and not the entire parent component. There's no right or wrong here.

Atrocious advice, I hope I never have to work in a codebase that follows these practices

willio58 5y ago

Specifically what do you not like? Some of it seems iffy to me but some of it also seems obvious e.g. “use components”.

purplerabbit 5y ago
I find almost every section to be extremely distasteful. for instance, points 2 and 3 basically suggest throwing YAGNI out the window in favor of premature abstraction. Combine it with the highly-decoupled style in point 1, and you have a nice spaghetti recipe. I could keep going, but it looks like everyone is piling on this poor guy already.
- activitypea 5y ago
  <3
activitypea 5y ago
I don't think there's a single paragraph in the article I agree with. In another comment, I picked on the parts that are the easiest to criticize in a shortish comment. The whole article screams bad OOP-style cargo cult programming, which I found particularly annoying :)
eliseumds 5y ago
It might be obvious to you. Hiding concrete implementations behind an elegant, easy-to-use interface, is not something we see every day. I've noticed countless codebases importing HTTP clients globally, mocking a ton of modules for testing, imperatively translating messages and so on. Wrapping implementations with components/hooks allows you to future-proof your application in case you need, for ex, to access some context data, to develop for a new environment (mobile, desktop), or for easier testing as already mentioned, including snapshots. I specially like that the author talks about wrapping third-party libraries. Another benefit of components is lifecycle. Imagine a "RelativeTime" component; you could have called library functions directly to render "20s ago", but by making it a component you could tell it to update periodically. Cool stuff. Now, I understand that having such granular components can lead to some performance overhead if you're working on a massive application. If only there was an easy way to do AST transformations that would hoist small stateless components/hooks. Damn, AST transformations could even hoist stateful ones! I'll keep dreaming about it :) In regards to examples such as `Fetch`, `UserRead` and `EntityActionDelete` from the post, I'm kinda on the fence because, at the same time they are uglier than hooks, they're also more performant because updates would only re-render itself and its children, and not the entire parent component. There's no right or wrong here.