Why Classes+Lifecycle Methods instead of Functions+Hooks with Nano-jsx?

[aadamsx]

Just wondering if you plan on adding the ability to use not just Classes and class lifecycle methods, but also of a more functional approach with hooks for client side state?

In other words, are there plans to add in hooks as an alternative to classes?

[yandeu]

I don't think. I prefer differentiating statefull (class) components and stateless (functional) components just like react used it before hooks.

[aadamsx]

Thanks for the reply.

I understand your thinking. But I think the JS community is moving to a more functional approach, and hooks are one approach to dealing with component lifecycles. I don't neccessarily think it's the best approach, but it's one that's use by most of the JSX community at the moment. To better in-line and keep pace with where JSX is headed, I think it makes sense to adopt the JSX approach and add hooks in, even if it's just optional.

Thanks again for a good library and the videos you make (yes, I'm going through all of them from the beginning at the moment).

[yandeu]

If someone makes a working PR, I will merge it.

Glad you like my videos :)

[aadamsx]

Just want to point out, if anyone is looking for a light JSX experiance (with hooks and a fimilar API) with Preact (or you can bring your own framework), with SSR/SSG and various hydration options, you can check this out: https://frugal.deno.dev/

[jrson83]

I love Nano JSX for most of my projects, but also switched for some to Preact because of that reason. I can recommend vite-plugin-ssr for a seamless integration with preact-examples.

[herudi]

@yandeu I experimented with nanojsx and hooks. maybe this helped.
https://github.com/herudi/nanojsx-hooks.

Thanks.

[yandeu]

Nice. Do you consider releasing this as a npm package?

[herudi]

I'm planning to release it.

by the way, useRef with nanojsx will write a bit longer than React.

Example useRef :

function MyComp() {
  const inputRef = useRef(null);

  useEffect(() => {
    // focus after 3s
    setTimeout(() => inputRef.current.focus(), 3000);
  }, []);

  return <input ref={(elem) => inputRef.current = elem}/>

  // React be like :
  // return <input ref={inputRef}/>
}

Thanks.

[yandeu]

I'm planning to release it.

Nice.

by the way, useRef with nanojsx will write a bit longer than React.

I would not notice. I have never used hooks in react.

[herudi]

now, i release it.

npm i nanojsx-hooks

[hbroer]

I am not alone, but there are not that many who think so, but hooks are the worst which came to React and from there to other libs like Preact. I am only here because this lib does not claim to be compatible to React. I am searching for an alternative to Preact/React which has no hooks at all. Why I am strictly against hooks:

1. They don't solve any problem but they cause many
2. They add a lot of boilerplate code to components and custom hooks, even that the intention was to remove some
3. They need a lot of knowledge when to use them, how to use them and what to avoid
4. Not easy to test
5. Not easy to apply dependency inversion (!)
6. They make the app more depending on the view-render-framework than it needs to be
7. And in summary it gets way more dirty than classic React apps. At least the projects I joined which use them are a hell to work on.

I have no problem with the fact that hooks exist in general. But the React devs choose to implement them in the core and forcing people to use them, instead of creating a new hooks based framework or a independent addon. Maybe there was the nice idea in the beginning of just adding a simple state to a stateles functional component but the idea to replace all class components with statefull functions was not a good idea and so even the good idea in the beginning was a bad idea at the end. As a dev who needs consistency over a long period of time for the projects I work on (they are not 4 weeks dev, fire and forget, they need maintenance and feature development over many years), React is today a absolute nogo for me for new projects.

[yandeu]

I feel the same. Also classes make the code look less "magic" and thus easier to understand.