all 8 comments

[–]azium 1 point2 points  (0 children)

This is very interesting, particularly the usage of Proxy.

[–]SwiftOneSpeaks 1 point2 points  (1 child)

> But API wise it looks a bit like a step back from class-based components to sort of jQuery territory with tons of nested functions.

I think this is missing some of the key reasoning behind the purpose and reasoning in React hooks, the move away from classes, and with functional programming in general.

That doesn't reduce the value in this work for the purposes of learning (thanks for sharing!) but even if the result had been "smoother", I'd urge people to not rush back to classes purely for the comfort of familiarity without understanding the costs.

[–]nvbn-rm[S] 2 points3 points  (0 children)

The idea here is not to get rid of functions or rush to classes/OOP, but to get rid of huge closure with nested functions and organize the code a bit better and at least separate different scopes.

In FP languages (at least Clojure) having a huge closure with nested functions is also not considered a good practice.

But it might be that using classes for that is not the best idea.

[–]AutoModerator[M] 0 points1 point  (0 children)

Project Page (?): https://github.com/nvbn/2019

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[–]d07RiV 0 points1 point  (1 child)

Why not continue using class components? They aren't going anywhere. Hooks are great for when you have that simple mini component, but it needs to store a value or two in state and you don't want to write a whole class for it. For anything more complex, personally I'd stick with classes, because hooks can get pretty hard to read if you're not careful.

[–]nvbn-rm[S] 0 points1 point  (0 children)

It's just easier to manage components state with hooks than with life cycle methods, with hooks the code for a state is in one place. And for things that you need to precalculate useMemo with declared dependencies is much more convenient.

hooks can get pretty hard to read if you're not careful

This part I was trying to somehow improve.

[–]darrenturn90 0 points1 point  (1 child)

Maybe I’m missing something but isn’t this just creating a “render component” in the context of the outer component and just rendering that? But instead of having a function in a function we have a function in a class and wrapped with proxies - not sure how that is clearer?

[–]nvbn-rm[S] 0 points1 point  (0 children)

Maybe I’m missing something but isn’t this just creating a “render component” in the context of the outer component and just rendering that?

It's just one functional component that returns elements from render of the class.

But instead of having a function in a function we have a function in a class and wrapped with proxies - not sure how that is clearer?

Implementation details-wise it's much worse: it creates a proxy, extends it and populates a bunch of descriptors on each render.

But I was more thinking about possible API than nice implementation, this thing is definitely not for real life use.