121–130 of 142 posts
Aren't most people hiring frontend developers looking for people who understanding Javascript (and not just React)?
Or is "React" a skill separate from Javascript these days?
Personally, I'd be hesitant to hire anyone who "knows React" but doesn't know the basics of how it works.
In some benchmarks this approach is 20 to 30 times faster than React.
Earlier quoted context omitted.
mostly because you can encapsulate and reuse some state logic. allows for easier testing too.
You could already do that with regular functions, class inheritence, mixin, prototype inheritence, composition, event dispatching or stores. If preventing people from being confused and doing the wrong thing was the goal, I'm not sure adding one new way to the mix is going to make things clearer. Besides, while I agree tooling help with applying good practices, including encapsulation, it's no substitute for a good i…
I'm guessing the site is built with gatsby from the theme.
> Please don’t turn this into an interview question. In fact, this post is more about JavaScript than it is about React. Aren't most people hiring frontend developers looking for people who understanding Javascript (and not just React)? Or is "React" a skill separate from Javascript these days? Personally, I'd be hesitant to hire anyone who "knows React" but doesn't know the basics of how it works.
Earlier quoted context omitted.
While I agree with your point, your example of React literally adds a DSL that requires a pre-compilation step. It's not required[0], I get that, but it's still a new language. [0]: It may not be required, but it was created for a reason....
I don't mind a pre-compilation step as I'm already doing it in my projects and a lot of the community is as well. There are other templating systems you can use in React if you don't like JSX. I've seen one codebase use direct calls to ReactDOM.createElement and there is a new hotness (which I can't think of the name of now) that replaces JSX with template literals, something like: function NamePetList(props) { retur…
Earlier quoted context omitted.
To me it's all about intent. By using a function instead of a class, you are basically saying "future reader, this component is nothing more than a simple mapping from those values to that DOM tree, don't try to look for internal states or any complex treatment here". Sure you could write a "normal React component without state" and do the same, but having those properties baked in the way you defined the component i…
I absolutely agree with you. This makes me very skeptical about the proposed feature in React, called "hooks", which is linked to in the article. It lets you add state to your functional components, and it looks like you end up bundling all your code into one function rather than having a separate constructor to initialise the state (to me, separating out that function is a good thing). I would be interested in the m…
Earlier quoted context omitted.
I've also had doubts about hooks since its proposal, and I agree with the points you raised. From the Rules of Hooks section in the documentation[0]. - React relies on the order in which Hooks are called. - Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions. - Only call Hooks from React function components. Don’t call Hooks from regular JavaScript functions. This design d…
> However, the community seems to have already welcomed it, so I'm forced to learn the intricacies to be able to understand React codebases and keep up with the latest trend.. That's one thing that no many realizes: the JS community is special and you should take that in consideration when adding a new features. When I say special, I mean it reacts (puns intended) in a way no other programming community does: - it ju…
Earlier quoted context omitted.
I'm quite sure the authors of Django would be able to tell similar stories about Python...
Yeah that's kind of the point of this blog. I dive a bit deeper than you need to know as an app developer. Also touched on this at the end: >If the final API is successful, its users never have to think about this process. Instead they can focus on creating apps.
If only it worked that way. Unfortunately, somehow I always end up needing to know about the process cause the abstraction leaks like a sieve. And it's leakier in javascript than in any other language.
“In the old days, JavaScript did not have classes” gave me a laugh. This was 3-4 years ago.