re: I made a mistake implementing a React Hook and got a denial of service from my backend VIEW POST

VIEW FULL DISCUSSION
 

This type of problem is because separation of concerns was broken. It's not the role of a UI component to deal with data fetching.
React's developers seem to have forgotten that React is supposed to be a view library. They are adding more and more "features" unrelated to that purpose. People misuse all these hooks / functionalities and lose sight of clean architecture. They will have more and more problems like you had.

 

Right now, React team's stand is that View is a very arbitrary term. What exactly constitutes a view?

I think the moment we are adding event listeners to our markup we are transitioning from simple markup template to adding business logic etc.

The good thing is we can still have separation of concerns. That's up to us. Separating components between Presentation and Container components is pretty common in React projects.

All in all, I think it's great React is making more things to make common scenarios easy to build. It's the first time a framework is attempting to solve data loading problem that causes jank or hundreds of loaders.

 

If the business use cases can not be tested without the UI, then the separation of concerns is broken. That's why a "view" has nothing of "arbitrary" and has a well defined purpose: present data.

Taking the code given in the post, to test the business use case of "receiving some data about meetings", the UI code needs to be run. That's wrong. React or no React.

And React is not a framework, it's a library. But you can create a framework using it, like some people have already done.

And React is not a framework, it's a library.

Regarding React being lib or framework, please check this thread. Ryan Florence says it's a framework. Actually there is no meaning in debating on this point.

If the business use cases can not be tested without the UI, then the separation of concerns is broken.

But in React, we render components and test them by checking if data is injected properly and things behaves a certain way based on various user events. That's the approach react-testing-library preaches.

The React community finds that MVC approach doesn't hold good on the frontend. Rather than divide by language (Controller- Js, View- Html) we divide by components. So one component has the responsibility of the UI and other logic of that piece. I have found this to be a better approach.

One thing though, if the end-result of some operation doesn't affect the view but only have side-effects on server or web storage then we can abstract them into functions (separate from React) and those can be simply tested like any other function

code of conduct - report abuse