You guys should come to New Zealand... working outside of your work hours is not cool here. More and more companies expect only 37 hours per week... a new trend is 4 days workweeks.
Nobody checking their email or phone after work... Ridiculous.
Same in the UK mostly (although there is a bit of this culture in London). I remember my first job, it got to 5pm and my boss gently prompted me to go home. He was happy to let me stay if I wanted to on occasion to finisb something off, but made clear that it wasn't expectsd or the norm. It's something I've stuck to ever since.
If you can't answer that without talking about what react broke first I don't think we we need whatever you're selling.
Added responses there too.
I feel like hooks are a solution to shit code that just needs a refactor.
This happens a lot in frameworks that try to please everyone all the time. You give people of all experience levels the same feature set. It's no wonder at least half your user base goes out back and shoots themselves in the foot.
If you want to fix this problem you need to remove flexibility. Not give them yet another method to hurt themselves.
I'd start by splitting component concerns. MVC might be a good candidate. React.fragment components tend to smell like fat models. Pure functions basically views and connect code/prop/state mapping looks a lot like controllers.
Fwiw this small UI component thing is originally what the MVC pattern was intended for. The big laravel style classes we have today are a misappropriation of the patterns name onto something that it shouldn't have.
They give you the ability to reuse stateful logic between components. You’ll need to be more specific about why it’s an “excuse” to you. Lots of people seem to find this ability useful.
They're excuses because none of them involve explaining when, where and how they are useful to a user.
They all basically say "framework needs it" or "we heard you like functions, so now we're getting rid of classes and making everything functions, but you still actually need classes and state and all that stuff so we're shoving state into globally accessible static functions that you have to call in the same order every time or things just won't work."
Like this whole thing is just absurd.
> They give you the ability to reuse stateful logic between components.
Stateful logic a code smell, we do not want this.
Redux actually gets this stuff correct - binding logic and effects to props and state should be done outside of the presentation layer.
I would have just fixed the redux API so people stop shooting themselves in the foot with it.
---
In any case, thanks for your comments, this has given me a lot to think about, I'm now wondering about how to replace useState with a prop named state. I'm also wondering if bi-directional prop mutation would solve all this cleanly - i.e. bind props instead of passing them, I think KnockoutJS did something like this.
She is right, doesn't matter how experience you are rejection hurts always. I agree, the best what we can do to change how we thing. Really great advices. Useful article. Thank you!
I have the same feeling. I would prefer to use classes rather than functions. More natural and nicely work with Typescript.
Luckily React is only a library and it is up to you how do you use it. I got used to working with classes and objects. For bigger and serious project I prefer Ember.js, which is modern and easy to pick up (https://yoember.com), but for some tiny project React is also a good choice with Typescript.
I guess hooks is a good option for devs who prefer functional programming.
Classes aren't really that great in React. You typically need do a lot of juggling to co-ordinate lifecycle hooks. Trying to do something like register, update and unregister a listener feels very verbose with classes because you don't truely control the instance lifecycle – React does.
Hooks work just fine in Typescript. Not just because Typescript already does will with Functional Programming, but because the types of most hook functions are generally rather simple.
`declare function useState<T>(startState: T): [T, (nextState: T) => void]` is pretty simple function signature and most cases Typescript picks up (infers) that T generic parameter for you based on startState. Almost every other Hook function has a similarly simple type signature, despite the complicated "guts" of how React keeps track of hooks internally. (Which also doesn't seem all that complicated, relatively speaking.)
(I still want a way to represent the order of effects / no effects in control flows rules in Typescript's type system, but linters will handle it fine. At this point it's mostly just a personal toy project/curiosity because Typescript feels like it has enough of the basic building blocks in the type system such as `never` to get quite close.)
This free tutorial helped me to understand the concept behind the framework. Actually, I can adapt this knowledge to other work also. https://yoember.com
You mean they would use something else instead? Most of the project who use Ember, they love it, and they would not use other tool. For example Intercom in Dublin is a huge supporter of Ember.js and they are big fun of the framework.
https://github.com/yzane/vscode-markdown-pdf