React hooks about crank HOT 7 CLOSED

As one of the maintainers of Preact, preact-compat and related libraries, I don't think people realise how much of an undertaking that is. It's a significant time investment and we only managed to pull it off because our rendering systems and component model is very similar to React's.

The main difficulties are timing related or in the order components are processed and their effects are called. I'm still amazed to this day that we did it and that it works so well, but getting to this point was a ton of work.

Crank is in a unique position to rethink the component model and I think working on anything else seems to me that it would just distract from Crank's main strength. Personally I'm way more interested in pushing the generator approach further than spending time on a compatibility layer.

Then people could start using it right away and right new logic in a new way.

Another angle to consider is that binding Crank to React severely limits room for experimentation. My experience with working on Preact is that users will rely on features in prod even if they're marked as highly experimental. Once they do they expect the framework to have a clear upgrade path with minimal changes to their code. It's another thing that can take away a lot of time and hinder experimentation.

from crank.

What Brian might not say is: there is a danger in "can you make this work like in React", and the answer being "yes" too many times, and then people complain that the library does not work like React (because it is not), and then all the people who were interested in it being "React 2.0" leave, and all the people who didn't care about its similarity to React and wanted something new have already left.

I could see someone writing a hooks shim that lets some Hooks code get reused, but I think it would be dangerous for Brian to do so.

from crank.

Hooks are deeply ingrained into React and using them would basically be a reimplementation.

This library can implement useState/useEffect in a way that lets you use hooks inside generators - though in order to keep that state internally you'd need an await:

const { isFetching, data } = await useQuery(query, fetch query);

Or something similar - though to be fair I think the benefit of hooks here is marginal. In this library you can just use regular vanilla JavaScript functions.

The way you'd reuse logic from hooks is you'd take the non-frameworky parts of the code (the library part) and just use that.

In your case - you'd just use graphql/apollo directly without having to go through a hook - which lets you use most of the code directly.

from crank.

Do you think something like python's 2to3, except react2crank, that makes a best effort at translating React to Crank but doesn't promise a perfect translation or perfect compatibility... you kiss your old code goodbye... would be more feasible? I could see that having some success if there was also sufficient test (or type) coverage of an application.

from crank.

What Brian might not say is: there is a danger in "can you make this work like in React", and the answer being "yes" too many times, and then people complain that the library does not work like React (because it is not), and then all the people who were interested in it being "React 2.0" leave, and all the people who didn't care about its similarity to React and wanted something new have already left.

I could see someone writing a hooks shim that lets some Hooks code get reused, but I think it would be dangerous for Brian to do so.

I agree. What I mean is not for Brian to code it and not for it to be included in the framework.
But to write some react-compat that will wrap existing hooks and make them work with Crank. Like preact-compat.
Then people could start using it right away and write new logic in a new way.
I am asking more experienced people whether this is even possible...

from crank.

I am thinking, if replacing each of these useEffect useState etc with crank equivalent, then such custom hooks could be used as is.
Then the adaption could be faster

from crank.

What Brian might not say is: there is a danger in "can you make this work like in React", and the answer being "yes" too many times, and then people complain that the library does not work like React (because it is not), and then all the people who were interested in it being "React 2.0" leave, and all the people who didn't care about its similarity to React and wanted something new have already left.

Plus one to this!

from crank.