@@lampshade5437 thanks so much for the feedback. It’s not too much attention to be honest. There might be one more video coming in the series. Not sure yet. But I really appreciate your nice words

@@feeyz6638 there were a few problems when passing the class based service functions as dependencies to the replyToShout function. I’d have to call the bind function for each of those methods which felt annoying. Finally a comment on Reddit pushed to the other more functional implementation

@@codinginflow yes, thanks

@@profydev Me too!

Thanks, I added it now

@@snivels thanks a lot for the feedback. I added the fetch functions to the infrastructure layer as they connect the app with external systems like rest APIs. The query hooks are an interesting question though. Putting framework code (here react hooks) into the infrastructure layer feels wrong because it makes that layer dependent on the framework. At the same time you probably have one query hook per endpoint and thus endpoints and query hooks are tightly connected. In the next episode I delay that decision by adding the query hooks to a separate “application layer”. But I don’t really like that approach and will refactor everything to reflect feature folders. Then I’ll add the query hooks to the infrastructure layer. Here’s the code for the next episode in case you’re interested: github.com/jkettmann/react-architecture/pull/15 About the domain layer: it should be isolated from infrastructure code like data fetching and independent of frameworks like react. So you would neither put query functions nor query hooks there. When it comes to the domain layer you can always ask yourself: “if I wanted to exchange react for something else could I leave the domain layer untouched?” If you can answer with yes then you already did a lot of things right 🙂

@@nickolaki Classes don’t work well with react because it requires immutability for state updates. In general classes offer nice encapsulation but here simple functions do the job as well

@@RJRobinsonX thanks a lot for the feedback

@@user-yz2mv8kn4x thanks for the feedback. I really appreciate it

You mean kebab case for file names? No that's not bad practice. In fact it has advantages over e.g. PascalCase when you or your teammates are on Mac: x.com/kentcdodds/status/1249870276688371713

@@BenjaminAbolade here it is. Check the PRs for the code changes for each video/article. github.com/jkettmann/react-architecture

In this case we have a couple of scenarios that basically lead to the same result: an error message shown in the form. If we’d test these scenarios with integration tests we’d have to use the same setup logic (e.g. clicking a button to open the dialog, filling out the form, submitting the form, and checking the error message). The only difference would be the API requests and responses. With the logic extracted into a function we can unit test each of these scenarios (which is faster and probably simpler). Then we only need one integration test that verifies that the error message is indeed shown in the UI

@@profydevfor the first part of the answer - you can abstract the repeated test logic to a function and reuse it across test cases

The reason I used a hook is to make it compatible with react query. But you’re right on this case we could use your approach which would keep it independent of react

@@profydev I see, you're building it for a future video. I guess if you have some of those as hooks you may as well make every one a hook just for consistency, it makes sense.

The reason I used a hook is to make it compatible with react query. But you’re right in this case we could just use a function