-
-
todomvc
Helping you select an MV* framework - Todo apps for React.js, Ember.js, Angular, and many more
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
However, I do have a lot of critique of your critique. - Similarity to AngularJS: Yeah, the code looks similar. But it's like saying JS and Java are similar because they look similar. You ignore a lot of pain points that AngularJS had with rerendering, state, side-effects, etc. - It seems to me that you want to write tests in a very "OOP" like manner. If you write tests with something like testing-library, the internal state of the component doesn't really matter, if the output (e.g. the DOM) of the component is as you'd expect it - using hooks and mocking only non-pure external calls should allow you to treat your component as a pure function - even with hooks. - It's much closer to the idea of a rendering library if you move your business logic to a hook instead of having it in your components. Hooks are just functions, and you can render them without having to write a component (again, with testing-library) - so you can test that behavior too, making it very easy to reason about. You really don't need any DI here. I feel like if you need DI in React, you are testing the wrong things and/or are writing weird components. - Hooks don't contradict using Redux. In fact, using Redux is a loooooooot easier with hooks like useSelector. - Not sure why you think going back to OOP patterns would make anything simpler than using hooks. The React Class API is very similar to Vue, and certain parts of Angular, and frankly I think it's a mess. - Never have I ever needed to pass dependencies to a hook. If you do that, you should probably redesign your hooks and/or how they are called.
With regards to separating business logic and rendering: by far the easiest way to do this is to use the Flux architecture, of which Redux is an example. However, you can also use React as the view layer of MVC frameworks like Backbone, as in this example. I wouldn't really recommend this though.
Here's a contrived example of a test on a list component. And here is the test harness. Even though this example is about components, all of these techniques are applicable to the renderHook api from react-testing-library as well. The test harness wraps the component under test with a react-query store provider, and ui library provider, and a navigation provider. It also provides a means to pass through your own ad hoc wrapper as an argument in the render api if there is some one-off context provider or something else you need for a particular component/hook so it has the dependencies it needs. Once these test harnesses are set up, getting new components/hooks under test is pretty trivial. But thought does need to go into how you design the argument signature of the test harness so you can expressively set it into some prerequisite state before running a test. An example of this is if you want redux to already have something in its store before a test runs.