Stack is a cloud native – site-based data central-platform PaaS, and we have an interesting open source project on Github and Gitee: FlinkX is a batch data synchronization tool based on Flink. It can collect static data and real-time data. It is a data synchronization engine with all-domain, heterogeneous and batch integration. If you like, please give us a star! Star! Star!
Github open Source project: github.com/DTStack/fli…
Gitee Open Source project: gitee.com/dtstack_dev…
People who have used React know that there are many different types of React project folders. The React official section on file structure provides some examples of common build methods in the community. For example, some are grouped by features or routes, and some are grouped by module type. In the documentation, Atomic Design is mentioned as a way to refine the organization of components. If have not understood this design method of friends, might as well have a look. What is Atomic
Atomic is a set of methods that guide the design of the front-end Components architecture. In our daily work, how to better partition and management of front-end components is often the problem we encounter. Atomic guides our project architecture with a set of design ideas and principles. In the words of Atomic author, the inspiration of this design method comes from the chemistry class I once studied and the reflection on natural knowledge itself. In this paper, five basic types of components, namely Atoms, Molecules, Organisms, Templates and Pages, are combined flexibly to meet our daily needs of page development.
1. Atoms
Atoms, as described in chemistry, are the smallest units of elements in which their chemical properties can be maintained, so using the concept of Atoms, you can use components of the smallest units in a system of components, or components abstracted to the smallest granularity, the basic elements we see in HTML, for example: Buttons, form labels, input controls, etc. Being the smallest unit, an Atom component is obviously not capable of being separated, and if it is, it should be classed as a molecular component.
We all know that in chemistry, a molecule is made up of several atoms. By combining atomic components, we can easily assemble functional molecular components. For example, by combining the input control with the Button component, we can have a Search molecular component, and by combining the Button and a tag, we can combine the Pagination component.
3. Organisms
The abstraction of molecular components and molecular components alone is still unable to meet the needs of component reuse in our practical work. For example, we have Navigation Bar, Header, Footer, Sidebar, List and other components in most of our projects. It can obviously be abstracted into individual components as needed so that later projects can use them directly. What we can see is that with atoms and molecular components, we can easily meet our needs by flexibly combining these atoms and molecular components. And the types of components that are combined in this way are called Organisms.
4. Templates
At this point, the template layer is easy to understand. Obviously, the template layer is a combination of atoms, molecules, and organic components. For example, a home page template with common sections of headers (Header, Content, Footer), or a variety of left, right, up, down layout template components, and so on.
5. Pages
The page layer is probably the one with the lowest reuse rate, as business requirements vary most of the time, and reuse of pages is not ruled out. The page component is naturally a composite of the other four component types. With the abstraction of the previous layers of components, various business pages can be easily handled, and new components can be continuously enriched into the types themselves for continued use in later projects.
Comprehensive look down, through the division of these five components, can be very good to meet our actual project on the page component division and management.
Using the SRC directory as the basis for the React project, I was able to get something like the following development directory:
Here is a Demo of the warehouse for reference:
Github.com/wewoor/atom… Third, summary
In actual work, often we will refer to the third party component library, so a lot of granularity components don’t need we write, only a small number of independent or we need to write, so will be cut according to own actual situation to the appropriate directory structure, including the directory name, in the case of communication with project members to agree, you can also use other naming rules. If you are designing a complete UI component system, or if you are developing a large Web system, then more detailed partitioning rules may be more beneficial for later maintenance and development.
Atomic is always a set of design ideas. In practice, we can make more flexible adjustments according to the situation of our business and team, so as to better meet our development needs.
See Atomic Design for more details:
Atomicdesign.bradfrost.com/table-of-co…