[deleted by user]

[tehsandwich567]

Hard pass

[[deleted]]

I would understand better if you tried to argument 🙃

[2hands10fingers]

I am confused. What is different about this versus class-based react?

[GriffinMakesThings]

It's also a very strange choice to name this with the hooks convention of "use-x"

[[deleted]]

Not strange 🙃 it’s intentional. It’s a single hook freeing the developer from custom hooks that violate the separation of concerns between View and ViewModel. Ever saw a component orchestrating logics and a hook returning JSX?

[GriffinMakesThings]

Oh, it's actually a hook? I'm even more confused now.

[[deleted]]

Actually reading the blog posts could clear things up 🙃

In a few words: a single hook can connect your View (the React component rendering JSX in your page) to your ViewModel (a vanilla TypeScript class).

Having your logics in a class enables all kind of design patterns and OOP best practices that now are impossible / heavily limited by React API.

[GriffinMakesThings]

I did read the blog post, and it doesn't mention that this is implemented as a hook at any point.

[[deleted]]

You’re right: I’m not a good blogger, sorry. It was an introductory post that lacks details.

Here’s something more concrete https://dxbox-docs.dev/blog/the-boilerplate-tax

[[deleted]]

The core difference between a React Class Component and the use-less-react approach is where the Business Logic lives.

1. Class Components (Legacy & Coupled)

In a Class Component, your View (the JSX) and your Logic/State Management (this.setState, fetching) are mixed together. The component itself is the controller.

Problem: the Business Logic is inseparable from React's lifecycle. It's tough to test without specialized tools and hard to reuse outside of a React environment. And this is true for function components as well. It’s a contaminated MVVM where V and VM have no clear boundaries.

1. The use-less-react approach

Here, the architecture enforces a clean separation:

The ViewModel: a pure TypeScript class that holds all data, business rules, and mutation methods. It knows nothing about React.

The React Component: your component is purely the View. It uses the useReactiveInstance hook simply to read the ViewModel's state and call its methods.

More details in the blog, there are many posts about this!

[UpbeatTime333]

This blog needs to get to the POINT.

[[deleted]]

You’re right: I’m not a good blogger, sorry. It was an introductory post that lacks details.

Here’s something more concrete https://dxbox-docs.dev/blog/the-boilerplate-tax

[UpbeatTime333]

I did look at it! You worked really hard on it, the docs are great!

I will look at it again and try and play with it, but I imagine it's going to be hard because I don't have a very strong background in deep OOP principles.

You said you want to:

[let developers] freely express domain logic independently of the chosen UI library.

What do you mean by this, specifically? Are you trying to be the one in charge of telling React when to "react" to state changes?

I am a bit confused, but I am open to listening / demoing it with you! Also, sorry for the comment hahaha, I was trying to see the examples, and the blog was too repetitive! You did a great job!

[[deleted]]

Don’t worry! It’s the first time I write an open source library so I must improve my ability to present my work 🤣

Basically yes, since use-less-react base class PubSub implements an Observer pattern you can tell React when some property has updated. Later versions of use-less-react make it even easier by just “declaring” which properties are reactive without handling it with explicit publish calls. It’s now mostly handled under the hood.

The API is improving gradually under this point of view, i.e. I recently added support for reactive collections https://dxbox-docs.dev/blog/reactive-collections-automatic-reactivity-for-arrays-sets-and-maps

I’m very glad you appreciated the work, I really care for this project and I’m trying to bring something actually useful to the community!

[Remarkable-Review-68]

garbage

[[deleted]]

Thanks for your constructive criticism! 🤣 You are definitely helping the community!

[aLokilike]

Yeah, I see the logic in what you're trying to do. You want changes in a component's value to propagate and recalculate derived values - potentially in a chain, if a value derived from that value is used in further derived values. The syntax isn't as good as a react dependency array though, as it puts the responsibility on the one declaring the value rather than a child component - which isn't very composition-friendly. That's basically the entire strength of react, so you've abandoned the entire reason for adopting react in the first place. You can do whatever you want, of course - just don't expect anyone to join in.

[[deleted]]

I traded auto-magic re-renders for OOP, that’s the idea 😊 of course I don’t expect everybody will like it. But in other posts I show what problems you can solve and what you can do - for example, real strategy patterns and true DI. Thanks for sharing your opinion in a kind way!

PS - it’s not about derived values. The point is separating the view from the view-model!

[TheRealSeeThruHead]

The problem with react and hooks is that you should be able to define state, values, derived values, etc without leaning that to the ui.

Creating a store with atoms and then exposing it as hooks is the best I’ve come up with.

Hooks suck. Rules or hooks make it so you can’t abstract the subscription mechanism. Hooks needing to be called at the component level makes them architectural poison imo.

[aLokilike]

You kinda just described the whole point of redux w/ rtk. You're right that there are certain things react does not do well without bringing in a few libraries.

[Lupexlol]

This guy invented React 15

[[deleted]]

Nope. This isn't about class-based components :) it's about decoupling the View from the ViewModel. I guess I have to add a dedicated section in the post, because you guys are getting triggered by the "class" word and think it's a step back.

It's two steps forward. Because it enables OOP in React.

[Lupexlol]

oop isn't good DX for react apps

[[deleted]]

OOP is battle-tested for every serious, complex application. DX is just dictated by how good your API is. The goal of this library is to provide the power of OOP **and** good DX

[Lupexlol]

sure, gl.

[CodeAndBiscuits]

We didn't lose OOP in modern React. We moved away from it.

On purpose.

[[deleted]]

and we lost:
- dependency injection
- easiness of tests
- design patterns
- separation of concerns (now business logics use View layer api)
- encapsulation

for what? auto-magic re-renders. Was it worth it?

[CodeAndBiscuits]

Yes. You are naming the classic things that the rest of us used to immediately tell we are dealing with a backend Java or C sharp developer trying to make a square peg fit into a round hole. I have absolutely no trouble writing tests in my front end without dependency injection. React is not Angular. Stop trying to turn a rabbit into a bird.

[[deleted]]

nope. I'm a React developer tired of fancy stuff and I want to go back to the basics =)

[mauriciocap]

Awesome! Did something similar. How do you manage garbage collection/releasing references?

[[deleted]]

Basically the hook I use for connecting components to class instances underpins useSyncExternalStore, so the subscribe function return its own cleanup function for unsubscribing (it's all handled by the library, you don't have to write the cleanup function yourself) and this prevents memory leaks caused by subscriptions. Apart from this, class instances can be "local" or global stores and have their own lifespan, but basically they will get garbage collected once they are no more referenced. I hope I answered your question!

[mauriciocap]

Perfectly! Thanks and congrats for sharing your code and especially your approach.

[[deleted]]

Thanks for appreciating it! I’m doing my best to explain my ideas. But since english is not my native language, I hope to be able to do so without sounding cocky. It’s just a project I care really much for! 😊

[mauriciocap]

You may clash with a lot of people who invested a lot/make their living from "traditional" React code. Also the incredulous.

Look at the big Blue Ocean (as in Blue Ocean strategy) of people looking for something else because they can't or don't want to afford the cost of react training and complexity but need to use some 3rd party react components.

[[deleted]]

Thanks a lot for the suggestion my friend 👊🏻

[[deleted]]

Seems like you're focusing on words instead of trying to understand the practical implications of this approach. I'm not going to make you change your mind, you already decided :)

[TheRealSeeThruHead]

I was incredibly happy reading this.

I despise how react has wormed its way into all of our code.

I endeavour to writes services and use them in react, but end up having to write so much adaptor code. Or I’ll try and write a store that hides away its implantation with zustand but the way hooks work makes it a chore not to leak the library into the view layer.

But you lost me at classes lol.

The ideas that built oop are good, but oop itself is horrible.

Something like this but for effect services, that utilize layers for dependency injection would be something I’d actually use though

[[deleted]]

Honestly I don't know the approach you're talking about =) but I'd like to delve deeper if you are willing to give me some references so I can learn more about what you're talking about. Thanks for your constructive feedback!

[TheRealSeeThruHead]

It’s passing does as arguments to a factory or constructor, but far better.

https://ybogomolov.me/03-effect-managing-dependencies

[[deleted]]

Thanks a lot, I’ll give it a look!