Skip to content

ArjunPatidarRadix/react-myntra-admin

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

13 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

React-myntra-admin

  • We have made this admin panel to add procuts, category, maincategory detail.
  • We can manage all registered users detail
  • We can add Offers from admin panel and display it on mobile app

Architecture

Applying clean architecture to a react codebase brings lots of benefits, most of them you can find by simply googling what's clean architecture and what should we adopt architectural patterns. One advantage that strikes me is having business rules isolated from framework-specific things. This means that our core logic is not coupled to React, React Native etc...
This gives you enough flexibility to, for example, move specific parts of the application to a backend, change libraries without too much pain, test once and reuse as many times as you want, share code between React and React Native applications, among others.

high-level-diagram

The nomenclature may vary, but the concept behind this architectural pattern is: the domain dictates how tools should be organized and not the other way around. What I mean by that is that we should organize our codebase around the business rules and not around the frameworks we use to achieve business rules. The diagram above shows how the dependency rule works, the inner circles must not know about the outer circles. That is, there cannot be an import of a use case within an entity, or import of a framework within a use case. Another important rule is: entities and use cases should not rely on external libraries. The explanation is simple, the core of our application must be robust enough and malleable enough to meet the demands of the business without needing any external intervention.

Communication flow

communication-flow-diagram

A brief explanation of each responsibility

  • Entity: Application independent business rules
  • Interactor: Application-specific business rules
  • Adapter: Glue code from/to Interactors and Presenter, most of the time implementing a framework-specific behaviour. e. g.: We have to connect Interactor with react container, to do so, we have to connect Interactor with redux (framework) and then connect redux to container components.
  • Presenter: Maps data from/to Adapter to/from Components.
  • Components: Simplest possible unit of presentation. Any mapping, conversion, MUST be done by the Presenter.

Folder Structure

This repository contains 2 examples of how to implement react following clean architecture, represented by the diagram above, and both follow the same folder structure:

./src
├── core
│   └── lib
│       ├── adapters
│       │   └── redux
│       ├── entities
│       ├── frameworks
│       └── useCases
├── native
│   └── src
│       ├── components
│       └── stylesheets
└── web
    └── src
        ├── assets
        ├── components
        └── stylesheets

Note: the frameworks folder comprises framework-specific setups to have it available to the adapters.

Releases

No releases published

Packages

No packages published

Languages

  • TypeScript 92.4%
  • CSS 6.2%
  • HTML 1.4%