Every time I see stuff like this componentDidMount() { I get driven away from React. It looks haphazard. Seriously? What about componentDidntMount() { componentWantedToMountButDidnt() { ... I'm used to clean naming conventions like void Component::on_mount() { .... }
The reason behind this different naming convention comes from the diversity in experiences of the original team. This will/did prefix instead of “on” comes from Mac OS X/iOS patterns and allows the name to convey the “when” of the listener. It is not “during component mounting” it is “after it did”.
Solid.js feels like what I always wanted React to be
41–50 of 444 posts
Re: Solid.js feels like what I always wanted React to be
#42What was wrong with the class component? It was very understandable and predictable.
Class components are fine for the simplest examples, but the moment they start increasing in complexity, they become a bit of a mess. Sharing functionality across multiple components becomes tricky with class components (with the only real option being HoCs / render props). You necessarily have to spread logic across different lifecycle methods. Hooks allow you to bundle code together by functionality, and consequent…
You’re using React. The mechanism that enables code reusability is through composing components.
There’s nothing wrong with class components even for the most complex logic. The only downside is the community has moved on and mostly adopted hooks and functional components.
Re: Solid.js feels like what I always wanted React to be
#43This feels a lot like knockout.js but with a jsx syntax.
Re: Solid.js feels like what I always wanted React to be
#44Hey I just finished my progressive web app with these 10 cool react components I found on NPM which fit surprisingly well into our startup’s cloud-native Vue interface.
I tried to put the code up on GitHub but it wouldn’t let me upload a 10gb repository (and that was without our proprietary fork of mysql :)
Re: Solid.js feels like what I always wanted React to be
#45I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…
This is just iteration on the awesome groundwork that React laid, and shows that things can still be much better. React has some very peculiar patterns that don't really jive well with javascript as a language, or its ecosystem. If the setInterval example is fundamentally against what React is, then IMO that really hammers the point the author is making. I have a few React projects under my belt, and often times stil…
Re: Solid.js feels like what I always wanted React to be
#46Earlier quoted context omitted.
The reason behind this different naming convention comes from the diversity in experiences of the original team. This will/did prefix instead of “on” comes from Mac OS X/iOS patterns and allows the name to convey the “when” of the listener. It is not “during component mounting” it is “after it did”.
I guess this is just a limitation of JS the language showing itself. Other languages have actual aspect-oriented support where before/after/around methods are very clear name-wise and semantics-wise (if not always so clear without tooling support what happens if you come across a 'mount()' call). Maybe it's time for a new JS framework! /s
Re: Solid.js feels like what I always wanted React to be
#47Earlier quoted context omitted.
https://www.solidjs.com/docs/latest/api#control-flow For reactive control flow to be performant, we have to control how elements are created. For example, with lists, a simple map is inefficient as it always maps the entire array. This means helper functions.
This feels like we're trading complexity here for complexity there, and it seems impossible to judge which way is actually "better". I use loops in React all the time but only have used `setInterval` in a component a handful of times..
Re: Solid.js feels like what I always wanted React to be
#48I am fundamentally skeptical of anything that needs a runtime for anything other than security and profiling. I am extra skeptical of any framework that needs 50mb memory baseline. I am triple skeptical of anything that uses brand-new packages and components like legos. *Iterations on React are welcome.*
Well, you can be skeptical, and the enterprise front-end engineers are going to go right on using that stuff because it scales to large codebase.
Re: Solid.js feels like what I always wanted React to be
#49Having used Solidjs for some pet projects, I've come to strongly prefer Solidjs over React. It's an evolution of react, so I've found my existing skills/knowledge transfers. This being said, Solidjs is brand new and the ecosystem is minuscule compared to React. For this reason, I plan to continue using React for the foreseeable future. One of the biggest weaknesses of Solidjs is the lack of a "nextjs" like framework. It appears work is being done in the solid-start[1] repo, but it looks like it's still years away from being fleshed out. I want Solidjs to succeed, but I'm not interested in being an early adopter.
[1]: https://github.com/solidjs/solid-startRe: Solid.js feels like what I always wanted React to be
#50What was wrong with the class component? It was very understandable and predictable.