2. Problem statement
• Application is getting bigger – the
monolithic approach doesn’t work well
• We need common structure and
development approach
• The input threshold and the connectivity
problem
3. Why do we need module architecture?
Module architecture is the type of architecture where an application is semantically
split on components.
For what?
• Development speed
• Scaling
• Reduced maintenance costs
• Decrease the input threshold
4. How to ensure the necessary modularity?
The modularity level depends on the scale of the application.
Everything that can be identified as a separate component / project should be separated.
What should we split?
• Main Components
• Data model
• Business logic
5. Modern React-Redux elements
Component – generic React component
Container – js-file to connect React component with state and actions
ActionCreators – creates actions for components
Reducers – change Redux store
State – describes Redux store
Selectors – select data from the store to containers, wired with State
6. The connectivity problem of React-Redux architecture?
In order for the project to be scalable and readable, it is necessary to ensure minimal
connectivity between modules.
12. What to do with styles and static
resources?
• Styles and static resources are in same folder with a component
• SASS is good, but JS-based styles have more options
• Create themes from the very beginning
13. 1. Create a domain oriented State model
2. Create a component (const or class)
3. Add styles in the same folder
4. Create other logic (actions, reducers, ...)
If it becomes more complex
5. Move the connection of props to containers
Algorithm for creating a React component
14. • It’s a clear way to work with state
• The same data model can be used in DB
• Build domain model from the beginning
Why do we need State model?
15. • Everything is sorted by domains
• It’s clearly easier to modify state
and selectors
export default class UserState {
public name:string;
public getName = (state) =>
state.user.name;
}
const mapStateToProps = (state, props) => ({
name: UserState.getName(state)
});
Wire selectors with state
16. • They need be standardized
• The same const between
modules, but different values
• They can be processed inside
different modules
enum ACTION_TYPE {
UPDATE_NAME = Symbol('UPDATE_USER_NAME')
}
export const updateName = (name: string) => ({
type: ACTION_TYPE.UPDATE_NAME,
name
})
then
import {ACTION_TYPE as USER_ACTION_TYPE}
from ‘./actions’;
What to do with actions?
17. • Code structure
• Simplify code maintenance
• Interface API
• There isn't strictly rule to use it
• First, the domain is developed in the
form of interfaces, then implementation
• Additional features (enam,… etc.)
Why and how to use TypeScript?
18. • JEST test are faster
• Tests are stored with components
• Different types of test for actions, reducers
and React-components
• Mocking is embedded into JEST
File structure
/scene1
/actions
/__tests__ -- unit
/containers
/components
/__tests__ -- snapshot
/reducers
/__tests__ -- unit
/state
JEST testing
19. Rules how to make snapshot
testing successful:
• Create very simple
components (no more
then 70 rows)
• Mock children components
• After a release of a
module override
snapshots only after a
code review
it("should render with a href, className, onDownloadClick and id", () => {
const props = {
href: "http://download.com",
className: "DownloadButton",
id: "id",
onDownloadClick: jest.fn()
};
const component = mount(<DownloadButton {...props} />);
expect(component).toMatchSnapshot();
});
SNAPSHOT testing