If you don't want magic don't use a framework
Introducing Hooks
301–310 of 310 posts
Re: Introducing Hooks
#302Re: Introducing Hooks
#303Earlier quoted context omitted.
At the end of the day, the framework that allows people to get more done with less thought is going to win the most mindshare.
That is unfortunately not true. The framework with the best marketing will win. That's why frameworks like angular and react are so popular. Both are designed to work well in large teams that work on huge codebases. Most of us probably would came along with much much simpler solutions.
So are you telling me Facebook has a serious marketing budget for React? If so, that means tech has gotten way way crazier than I could ever have imagined.
There's a complexity angle that needs to be appreciated. I love Rails, I think it's the best solution to the problem it tries to solve for the people it wants to solve that problem for. But it's been called overly-complex and magical. But less-complex, less-magical frameworks just don't solve the problem as well. Just try building something big with Sinatra and you'll see what I mean.
I'm not terribly familiar with Angular, but React, when you remove it from its ecosystem and treat it as just a library-framework, does a great job at facilitating the building of user interfaces. The abstractions and underlying paradigm are somewhat hard to grasp, but once grasped, a competent architect can lay down patterns that juniors can implement.
A lot can get done in a small amount of time with React. The people that managed to do this in the beginning are the ones who christened React the Son of UI Development. People listened, and now we have the Church of React, with the Redux Reformation now upon us. Facebook had nothing to do with it, that was all us.
Re: Introducing Hooks
#304My gut reaction is that Hooks isn't the greatest addition to React. One thing I've always pitched about React is the clean and extremely explicit API (with `dangerouslySetInnerHTML` being my favourite example). The hooks API is taking the dangerous road down to implicitness and magic which can only ever mean bad things in my book. It's really not clear to me how calling the setter for these individual pieces of state…
After pouring over this API for the last 3 days and keeping up with the RFC, I think I have reversed my position. I felt I couldn't leave this comment like this because it doesn't reflect my opinion anymore. I think hooks are amazing. If the React team can nail the API down, I think hooks will be revolution in how we work in React. I still feel like it will make the barrier for entry a little harder but as an experienced React dev, they're fantastic.
Re: Introducing Hooks
#305Earlier quoted context omitted.
> because it's apparently hard to work out all the ways that the method could be invoked Simple example case of a statement that makes it impossible to minify function names: class Test { static func() { /* function code */ } } test[prompt('function to call')]()
Doesn’t that example also make it impossible to minify the names of anything? Perhaps other than JavaScript modules, since AFAIK the popular module builders like Webpack do compile-time module importing (I believe that even the dynamic import function is recognized at compile time and doesn’t support throwing in a prompt).
No, that issue is unique to class/object property names. You can't dynamically reference a variable in a scope by name supplied by a variable in the same way (except by using `eval`, which does in fact cause minifiers and javascript engines to disable a bunch of optimizations in the scope it's used).
Re: Introducing Hooks
#306Earlier quoted context omitted.
You don't add properties to the strings object, but use is as a key into a WeakMap.
The strings object doesn't seem to differ based on call site. > f = l => l [Function: f] > f`hi` === f`hi` true
What JS VM did you use? Edge/Chakra has a bug, but it's been fixed. That expression should return false in Chrome, Safari and Firefox.
Re: Introducing Hooks
#307My 2c on the hooks cause:
https://github.com/salvoravida/react-class-hooks
Use Custom Hooks with React Class Components. Compatible React >= 16.0.0
Re: Introducing Hooks
#308Earlier quoted context omitted.
I think it's best to treat the various hooks the same as method definitions: you wouldn't conditionally define componentDidUpdate or componentWillUnmount in a class component. Instead, you would conditionally do something within those (always-present) functions. The same applies for these hooks.
I had this thought as well. Ironic isn’t it, given that the main reason for hooks is that “classes are hard”.
I'm unsure what's ironic about it. Hooks feel significantly easier to me than classes in a bunch of dimensions.
Classes come with a whole lot of syntax & concepts like constructors, instance vs class properties, autobinding, that are otherwise not used at all in React. They present barriers to optimizing code with compilers, and property names don't get minified.
Hooks are Just Functions though. They don't even have to deal with the most confusing aspect of functions in JS: "this"/calling context. You could easily consume them in ES3 by just not using array destructures and function keywords and it would barely get less readable.
Contrast this with classes, where new devs are often pushed to learn experimental and often-changing syntax just to avoid the awkwardness of working with the current specification for classes in JS. The following isn't allowed per the spec or any stage 4 proposal, but it's all over intro tutorials so that people don't have to manually bind methods in the constructor.
class Foo { handleClick = event => {...} })Re: Introducing Hooks
#309Earlier quoted context omitted.
I’ve seen this discussion pop up before in other frameworks I have used as they evolved over time. Interestingly enough my favorite framework went from being very magic to being less magic and more explicit and verbose. I liked it better when it was more magic. Guess I’m in the silent group who isn’t bothered by a bit of magic, and actually likes it. Sometimes I don’t care too much what’s going on under the hood so l…
Magic is great when it works. The problem is when it doesn't do what you are expecting, it can be much harder to troubleshoot. (Did I do something wrong? Am I hitting a bug?) Magic hides internal details, hence users are less familiar with them, hence they struggle more to diagnose when the magic fails to happen.
Don't want to be rude. But, the truth is, it is only a magic if you just can't figure out how they implement it...
Re: Introducing Hooks
#310There are a lot of gotchas with these. Don't call in conditionals, branches, loops. Can only be called from function components. Order of invocation matters (yeck!) If the goal is helping developers "fall in to the pit of success" I think classes are a much better option than this.
There are a lot of gotchas with the object-oriented way of doing these things too. Don't set `this.state` directly, don't forget to keep your side effect logic in `componentWillMount` parallel to your cleanup logic in `componentWillUnmount`, et cetera.
[deleted]