React: decoupling UI and business logic

Hello everyone and welcome to our third stream! At the end of our last stream we managed to have a working React form, so now it is time for us to leverage the benefits of TDD and refactor our component to decouple presentation and business logic. We will discuss how to restructure our components to achieve less coupling, and some of my personal preferences in terms of organizing React applications. Here are the details of today:
1. Where did we stop?
2. Why do we need to decouple?
3. Structuring our folders and files
4. Creating tests for the upcoming components
5. Refactoring our React form
The overview and schedule of today's stream can be found here: lauromueller.n...
This streaming is part of a series where we are organically developing a productivity app with React and TypeScript. We will focus on implementing Agile and XP principles in our series, which means we will focus on TDD, continuous delivery, feature flags, and a lot of other cool stuff that we have to take care of to have our app deployed to production as quickly and as often as possible.
---
You can support the channel on the following links, or by getting any of the books mentioned in the list below (which I highly recommend as readings to improve your developer skills and mindset).
Patreon: / lauromueller
PayPay: paypal.me/laur...
Here is my personal list of books:
The Pragmatic Programmer: journey to mastery - amzn.to/3BjrAiW
A Philosophy of Software Design - amzn.to/351Gv5y
Fundamentals of Software Architecture: An Engineering Approach - amzn.to/36e96oK
Software Engineering at Google: Lessons Learned from Programming Over Time - amzn.to/3szfrCs
Refactoring: Improving the Design of Existing Code - amzn.to/3BiomfL
A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware - amzn.to/3JpkKeE
Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems - amzn.to/3sFpTZt
Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation - amzn.to/36ek4up
Implementing Domain-Driven Design - amzn.to/3GQ8r9m
Test Driven Development: By Example - amzn.to/3syMhUc
Building Event-Driven Microservices: Leveraging Organizational Data at Scale - amzn.to/3gKmoev
Follow me on Twitter for tips and articles on programming, and for being always up to date about the next streamings: / lauromueller
---
Music by ‪@Lofigirl-Chillbeats‬

[@WebDevCody]

This was an excellent walkthrough on a lot of different concepts. I will say that sometimes we add complexity to achieve decoupling. We went from a single react component that could easily be read in one passing glance, into 5 different files all for the sake of decoupling. I’m not saying what you did is wrong, I’m fact we do similar things on my project, but we should also continuously consider if we’ve gone off the deep end into the dogma of following DRY or SOLID in exchange for losing KISS. Just some thoughts that constantly haunt me lol

[@LauroMueller]

You are absolutely correct! There is such a thing as over-engineering the solutions (including decoupling), and the project in this series of videos is still too simple to demonstrate these concepts to their full extent. I think my goal here was more to discuss the principles behind decoupling, so that those watching the videos can take these principles and apply to the projects they are working on (which are probably more complex than todo lists and productivity apps 😅 ). That being said, when in doubt I normally err on the side of decoupling and encapsulation because of their long-term benefits of isolating parts of the code.

[@rikschoonbeek]

Thanks for this! I want to learn more about things like interfaces, coupling, cohesion, dependencies, and stuff like that. I found this video while thinking about separating business logic in React to make code more readable and maintainable, but I am also reading a bit about the SOLID principles recently, and I expect that you may be implementing some of the SOLID principles here as well. I like how you explain your thinking, the different concerns. I think I could learn some good practices from listening to you more.

[@LauroMueller]

That's wonderful, Rik! I'll definitely keep that in mind, and will bring up a more extensive discussion around the SOLID principles in one of the upcoming videos.

[@hansschenker]

Totally agree structuring your app directory into feature directories. All things Task related should live in the tasks (plural) directory. In the best case you should be able to reuse the folder somewhere else without changing anything. Tasks is self contained!

[@michalkotlicki4710]

awesome channel btw. You give me a lot to think about

[@LauroMueller]

Thanks, Michal!

[@youcefzahariou9983]

thank you so much for sharing man

[@LauroMueller]

You're welcome!

[@whiskas-1]

You can simply put an async function in there, right? 1:17:13 I'm asking just to understand if you have a specific reason to use the `new Promise`

[@LauroMueller]

Yep, you are correct! I guess it's the "tunnel vision" that happens when focusing during the streaming 😅

[@JurrAFC]

Thanks for sharing this material! I didn't know about the git add -p . 🤯. Are you using the TDD in your "day to day work" on FE ?

[@LauroMueller]

Welcome! Yep, always trying my best to follow TDD practices :)

[@capableText3]

🇺🇦 Thank you for your support, it means a lot for us

[@c-far7050]

Hi Lauro, i am facing a strange behavior with user.keyboard('123') . the useState is assigned the value on button submit. and is displayed in a h1 tag. the value in h1 tag is reversed . how can i fix it ? i am unable to find anything on google. Thanks

[@LauroMueller]

Hi! Are you using the "await" keyword in the user.keyboard() command? Everything in user-events is asynchronous, I've constantly ran into issues when forgetting to add the "await" keyword. So: await user.keyboard('123'); Could potentially solve the issue? Apart from that I don't really have anything in mind regarding what could be the issue 😅

[@c-far7050]

@@LauroMueller interesting enough.. the output was 321... and it can be the keyboard input and its appending ... since last typed character is 3 and it appends it to the beginning ... may be thats the case :D

[@michalkotlicki4710]

Should we extract every`useState`, `useReducer`, `useSelector` to custom hook, like you did with `useTasksStore`?

[@LauroMueller]

I wouldn't say "every", but I do like the idea of abstracting how the state is saved from the component itself. That being said, doing it too much will make the code more complex to understand and manage, so there is a trade-off we need to keep in mind here.

[@michalkotlicki4710]

The problem with using classes is that, when you fetch data you get the json object, and then you have to manually map json data to appropriate instantiated classes.

[@LauroMueller]

Personally, I don't see that as a problem, but rather as a good layer of abstraction that decouples our application from the data that is received via the network. Since network communication is normally at the boundary of the system, I'd argue that having this decoupling can have long-term positive consequences by keeping the core logic of the application independent of the data structure passed via the network. Granted, there is some additional effort to map the fields that we receive to class fields, but this also has its advantages in the sense that we gain full control over how the data is stored in the classes, together with which data is exposed to other components. So also goes in the direction of supporting good encapsulation.

[@michalkotlicki4710]

The same `Task` class could be used in different features. If we include more methods in the `Task` class, then some of the methods are used in one feature, but are not used in the others. We are exposing methods, that are not needed in some features. It breaks encapsulation. If we have just loosely coupled pure functions instead, then we could define them separately in the features, that are actually using them. Isn't it better?

[@michalkotlicki4710]

Basically this is a question how should we group up the data and actions. Should we group actions with corresponding data like with class approach or should we group actions by features using pure functions in utils files

[@LauroMueller]

Well, that's the million-dollar question 😅 These are the two main paradigms in programming: OOP and functional programming, and there are arguments to both sides. I do like pure functions a lot, but I also see the value of using classes. Perhaps we could find better abstractions than `Task` (which is quite concrete when I think of it), such as `Schedulable`, `Completable`, etc., which would prevent grouping unrelated methods under the same interface. If we want to go one step further, we can then combine these abstractions with pure functions for the functionality.

[@viniciusataidedealbuquerqu2837]

why you need to setup the user?

[@LauroMueller]

That's a necessary setup for the testing library to work properly. Here is the documentation page: testing-library.com/docs/user-event/setup/

[@tameramer1465]

Wonderful Laoro👏👏 Sind Sie Deutscher?

[@LauroMueller]

Danke danke! Eigentlich nicht (trotz der Nachname), aber ich wohne hier schon seit ungefähr 7 Jahre :)

[@vikrantshah1633]

Love the content bro, but it’d be grate if you skip the tests in stream Makes the content unnecessarily longer than it needs to be

[@LauroMueller]

Thanks for the feedback :) That's one of the problems I noticed as well, which made me go back to recording the videos and editing these parts out. Maybe I can dedicate future streamings to more interactive sessions (like Q&A, for example) and not to code?