mirror
/
front-end-interview-handbook
mirror of https://github.com/yangshun/front-end-interview-handbook.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

contents: misc system design contents

This commit is contained in:
Yangshun 2021-09-26 18:16:15 +08:00
parent 4a99db5d0e
commit 2a4d146785
2 changed files with 12 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
contents/front-end-system-design-applications.md
View File

@ -22,8 +22,8 @@ sidebar_label: Applications
- Performance
- Accessibility (a11y)
- Internationalization (i18n)
- Security
- Multi-device support
- Security
### Requirements clarification
@ -43,15 +43,19 @@ For applications, common architectures include Model-View-Controller, Model-View
### Data model
Client app state.
Client app state, which is a combination of server state (database) and true client state (non-persisted to the server).
TBD.
### API design
API design for applications will refer to the HTTP/network API parameters and the shape of the responses.
TBD.
### Deep dives
With the basics of the application covered, we can dive into specific areas which the application might need special attention to. Note that there almost definitely won't be enough time to cover every area, and not every area will be very relevant to the component at hand.
With the architectural basics of the application covered, we can dive into specific areas which the application might need special attention to. Note that there almost definitely won't be enough time to cover every area, and not every area will be very relevant to the component at hand.
Showing knowledge about these areas and being able to dive deep into them are traits of senior developers.

9
contents/front-end-system-design-ui-components.md
View File

@ -20,8 +20,8 @@ sidebar_label: UI Components
- Performance
- Accessibility (a11y)
- Internationalization (i18n)
- Security
- Multi-device support
- Security
### Requirements clarification
@ -49,7 +49,8 @@ Deciding what data to put in state is essential to doing well for this portion.
- State is allowed to change over time during the lifecycle of the component, typically as a result of user interactions
- Each component has its own state which allows _multiple instances_ of the component to coexist on a single page. The state of a component instance should not affect the state of another instance
- If a component uses a value which can be derived from another piece of state, then that value should most likely not be part of the state. For example if your component is rendering a list of items and you want to display a message when there are no items to render, there shouldn't be an additional `isEmpty` state because it can be derived from the length of the `items`
- Components are easier to reason about (read/understand) the less state there is. We should strive to reduce the amount of state needed. If a component uses a value which can be derived from another piece of state, then that value should most likely not be part of the state. For example if your component is rendering a list of items and you want to display a message when there are no items to render, there shouldn't be an additional `isEmpty` state because it can be derived from the length of the `items`
- If a component has multiple sub-components, it'll be best if it's possible to consolidate the state within the top level and the rest of the components are pure and stateless
### API design
@ -133,11 +134,11 @@ Is the component expected to be used on mobile web? Mobile devices have unique c
Most of the time, components aren't exposed to security vulnerabilities, but it can still happen. Here are the more common security vulnerabilities you should be aware of:
- XSS - Is your component vulnerable to cross-site scripting (XSS)? E.g. do you render user input via `.innerHTML` or `dangerouslySetInnerHTML` (React-specific)?
- XSS - Is your component vulnerable to cross-site scripting (XSS)? E.g. Do you render user input via `.innerHTML` or `dangerouslySetInnerHTML` (React-specific)?
- CSRF (Cross-Site Request Forgery)
- Clickjacking
- [`rel=noopener`](https://mathiasbynens.github.io/rel-noopener/)
## Helpful articles
- [Buillding an accessible autocomplete control](https://adamsilver.io/blog/building-an-accessible-autocomplete-control/)
- [Building an accessible autocomplete control](https://adamsilver.io/blog/building-an-accessible-autocomplete-control/)