react-with-clean-architecture VS clean-react

I found this project (https://github.com/falsy/react-with-clean-architecture) that I might use as a practice before doing the real thing. I also came across this example (https://github.com/christophehurpeau/nightingale).

Rodrigo Manguinho em Clean React

In src/presentation/pages/ the Login page will be created, which is composed by components, methods and functions. The component that calls the authentication function is the that is contained in the form to get the input values, as shown in the following code snippet: Enter fullscreen mode Exit fullscreen mode When clicking on the Button, the handleSubmit() that is in the onSubmit of the form is called. const handleSubmit = async ( event: React.FormEvent ): Promise => { event.preventDefault(); try { const account = await authentication.auth({ email: state.email, password: state.password, }); setCurrentAccount(account); history.replace('/'); } catch (error) { // Error handling here } }; Enter fullscreen mode Exit fullscreen mode Where the authentication.auth() on click will call a factory (we'll see later) to do the authentication. In this case, it is passing the parameters captured by the input and the value returned from the request is saved in the cache through setCurrentAccount(account). Fourth step: Connect all layers for requests to work After everything is implemented, now just connect all the parts. For this, the design pattern Factory Method is used. Inside src/main/factories/usecases we create the factory of the use case being implemented. In the case of this example, it is related to authentication. The makeRemoteAuthentication is created, which returns the RemoteAuthentication that receives as a parameter the factory of the Http Client and the factory that creates the URL. The URL of the API you want to request is passed as a parameter along with the factory that creates the URL. In the example it is the URL that ends with /login. import { RemoteAuthentication } from '@/data/usecases/'; import { IAuthentication } from '@/domain/usecases'; import { makeAxiosHttpClient, makeApiUrl } from '@/main/factories/http'; export const makeRemoteAuthentication = (): IAuthentication => { const remoteAuthentication = new RemoteAuthentication( makeApiUrl('/login'), makeAxiosHttpClient() ); return remoteAuthentication; }; Enter fullscreen mode Exit fullscreen mode After that, in src/main/factories/pages, the folder for the Login factories is created. In pages with forms, form validations are also injected, but as the focus of this text is on integrations, we will leave this point out of the explanation. import React from 'react'; import { Login } from '@/presentation/pages'; import { makeRemoteAuthentication } from '@/main/factories/usecases/'; const makeLogin: React.FC = () => { const remoteAuthentication = makeRemoteAuthentication(); return ( ); }; export default makeLogin; Enter fullscreen mode Exit fullscreen mode A makeLogin const representing the factory is created. It has makeRemoteAuthentication which is injected inside the Login page created in the presentation layer so that the page has access to these requests. Fifth step: Apply the page created in the application Finally, it is necessary to call the Login factory in the application, so that it can be accessed by the user. In the router.tsx file located in src/main/routes, add the factory page created into the Switch inside BrowserRouter. The route is passed in the path, in this case it is /login, and the page in the component, which in this case is the pointer to the makeLoginPage factory . This logic is used with all other pages, only changing from Route to PrivateRoute if the route is authenticated. The code looks like this below. const Router: React.FC = () => { return ( ); }; Enter fullscreen mode Exit fullscreen mode Conclusion Clean Architecture despite being a bit complex to understand and implement at the beginning - and even seem redundant -, abstractions are necessary. Several design patterns are applied to ensure the quality and independence of the code, facilitating the evolution and independent maintenance of the framework. In cases like this, if you want to change the framework from React to Angular or any other Typescript based framework, just change the presentation layer and make adjustments to the dependencies. Following the development process and understanding why you are doing it in such a way makes code production easier. After a while it ends up being done naturally, as it has a linear development process: I. Use case in the domain layer; II. Use case in the data layer; III. Creation of UI in the presentation layer; IV. Creation of factories to integrate all layers into the main layer; V. And the call of the main factory in the application routes. As the example has many abstracted parts, it is recommended that you read the code for the hidden parts for a better understanding. In this repository you can access abstracted code similar to the one given in this example. You can also access this architecture just by running the npx @rubemfsv/clean-react-app my app command, similar to create-react-app, but in a cleaner and more scalable way. Find out how to do it reading this post. References Rodrigo Manguinho https://github.com/rmanguinho/clean-react MARTIN, Robert C. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. 1st. ed. USA: Prentice Hall Press, 2017. ISBN 0134494164.