From 937cb12529bdbb78170e90e8783899fca228531e Mon Sep 17 00:00:00 2001 From: Yangshun Date: Tue, 8 Apr 2025 20:54:06 +0800 Subject: [PATCH] feig: tweaks --- .../en-US.langnostic.json | 20 +++++------ .../en-US.mdx | 21 ++++++----- .../zh-CN.mdx | 35 +++++++++---------- .../user-interface/en-US.langnostic.json | 4 +-- .../contents/user-interface/en-US.mdx | 2 +- .../contents/user-interface/zh-CN.mdx | 2 +- 6 files changed, 41 insertions(+), 43 deletions(-) diff --git a/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.langnostic.json b/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.langnostic.json index a13082c73..a9ad36b1d 100644 --- a/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.langnostic.json +++ b/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.langnostic.json @@ -12,21 +12,21 @@ "hashes": [ "7f1fffed", "81cc1826", - "bdb69cc8", + "1ebd485d", "900e38b", "d3697278", - "1c6e60e8", + "100f898a", "7ec059be", "e2c69bb6", "1d54ea6d", - "8ec8cc8e", + "881f476e", "117c7433", "5f4ca2bc", "fda09b00", "1ec3f9b9", "14e70e0f", - "5f89ebf6", - "4b290d06", + "c13208eb", + "1480761c", "91cda1b7", "3b3e557d", "7ef0c666", @@ -61,21 +61,21 @@ "zh-CN": [ "7f1fffed", "81cc1826", - "bdb69cc8", + "1ebd485d", "900e38b", "d3697278", - "1c6e60e8", + "100f898a", "7ec059be", "e2c69bb6", "1d54ea6d", - "8ec8cc8e", + "881f476e", "117c7433", "5f4ca2bc", "fda09b00", "1ec3f9b9", "14e70e0f", - "5f89ebf6", - "4b290d06", + "c13208eb", + "1480761c", "91cda1b7", "3b3e557d", "7ef0c666", diff --git a/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.mdx b/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.mdx index a04f5ea57..7fd241eea 100644 --- a/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.mdx +++ b/packages/front-end-interview-guidebook/contents/user-interface-questions-cheatsheet/en-US.mdx @@ -12,19 +12,19 @@ Here are some tips you can use to improve the user interfaces you have to build/ - **Break down the problem**: Break down the problem into stages/milestones that build on top of each other and write your code progressively. - **Test frequently**: Test the UI in the browser after you complete every feature so that you can catch bugs early. Bugs caught earlier are easier to fix. Make sure the current feature is working before moving on to the next feature. -- **Use JavaScript frameworks if possible**: Your life will be very hard if you choose to build complicated UI using Vanilla JavaScript as the code can get very long and messy quickly. We recommend building apps and games using a framework if possible. -- **Think ahead and plan accordingly**: Think about what features your interviewer might ask you to add next. Design your code in a way that makes it easy for new features to be added. +- **Use JavaScript frameworks if possible**: Your life will be very hard if you choose to build complicated UI using Vanilla JavaScript as the code can get very long and messy quickly. We recommend building apps and games using a JavaScript framework/library (e.g. React, Vue, Angular, etc.) if possible. +- **Think ahead and plan accordingly**: Think about what features your interviewer might ask you to add next by drawing from your experience in building real-world applications, using libraries, or from practicing interview questions. Design your code in a way that makes it easy for new features to be added. Most of the time you would be asked to component-ize your UI so that multiple component instances can be shown on a page – modularize and avoid relying on global states or polluting the global namespace. ## Component organization How do you structure your code? -- **Adopt the [Container/Presentational Pattern](https://www.patterns.dev/posts/presentational-container-pattern/)**: To achieve good decoupling, rendering code should be agnostic to the source of data. Separate components into an outer one that provides the data and an inner stateless one that renders the view based on the data. This makes it easy for the view to switch from local component/app state to data loaded from the network and vice versa, you only have to change the outer component and the inner component can be used as-is. -- **Break down the app into subcomponents**: If the UI has multiple parts, break the UI into smaller components and identify the props/state needed by each component. +- **Adopt the [Container/Presentational Pattern](https://www.patterns.dev/posts/presentational-container-pattern/)**: To achieve good decoupling, rendering code should be agnostic to the source of data. Separate components into an outer layer that provides the data and an inner stateless one that renders the view based on the data. This makes it easy for the view to switch from local component/app state to data loaded from the network and vice versa, you only have to change the outer component and the inner component can be used as-is. This separation also facilitates testing of the presentational component as the required data can be easily mocked. +- **Break down the app into smaller components**: If the UI has multiple parts, break the UI into smaller components and identify the props/state needed by each component. - **Minimal API surface area**: Don't pass excess data to inner components which don't need them. -- **Component instantiation**: When asked to build UI components, define APIs (usually functions) to allow creating multiple independent instances of the components along with configurable options and defaults. Avoid writing code (e.g. relying on global variables) that prevents separate UI component instances from being created. +- **Component instantiation**: When asked to build UI components, define APIs (usually functions) to allow creating multiple independent instances of the components along with configurable options and defaults. Avoid writing code (e.g. relying on global variables) that prevents multiple UI component instances from being created. - **Vanilla JavaScript**: Create a function that takes in a DOM element (the container element) and an options object. Within the function you can dynamically create DOM elements and append to the container element. Another source of inspiration for a component API is [jQuery UI](https://jqueryui.com), but that has a dependency on jQuery. - - **Other JavaScript UI frameworks**: Most modern JavaScript UI frameworks like React forces you to think in terms of components by default. + - **Other JavaScript UI frameworks**: Most modern JavaScript UI frameworks (e.g. React, Vue, Angular) force you to think in terms of components by default. ## State design @@ -32,9 +32,8 @@ State is data that changes over time in your UI, commonly due to user interactio Most UI questions in interviews will require state and designing the state well is paramount. -- **Determine the minimum state needed in your UI**: The smaller the state, the easier it is to read and understand the code -> lower likelihood for bugs. - - Identify essential state vs derived state. Derived state is state that can be calculated from essential state. -- **Separate rendering code vs data management code**: Make the UI a function of your data and separate your code into two groups (rendering code and data management code) for better readability. If you use JavaScript frameworks such as React, you will more or less be forced to do so. +- **Determine the minimum state needed in your UI**: The smaller the state, the easier it is to read and understand the code -> lower likelihood for bugs. Identify essential state vs derived state. Derived state is state that can be calculated from essential state. By deriving the state on-the-fly you reduce the possibility of state values going out-of-sync. +- **Separate rendering code vs data management code**: Make the UI a function of your data and separate your code into two parts (rendering code vs data management code) for better readability. If you use JavaScript frameworks such as React, you will more or less be forced to do so. - **Use the state-reducer pattern for complex state interactions**: If the question requires many state fields and certain actions require changing multiple fields at once, use a [reducer to consolidate state update logic](https://beta.reactjs.org/learn/extracting-state-logic-into-a-reducer). First popularized by Redux, the state-reducer pattern encourages you to determine the state of your UI, actions that can be taken, and how to combine actions with state to derive the next state. If you are using React, you can achieve this pattern via the [`useReducer` React hook](https://reactjs.org/docs/hooks-reference.html#usereducer). Redux is usually overkill for interviews and `useReducer` should be sufficient. [React's](https://beta.reactjs.org) docs on ["Managing State"](https://beta.reactjs.org/learn/managing-state) is an excellent resource on how to design and use component state correctly. Some of the ideas mentioned aren't specific to React and can be applied to any UI frameworks. @@ -48,11 +47,11 @@ Is your JavaScript using modern language syntax and good practices while avoidin ## HTML -Are you writing semantic HTML with the right attributes? +Are you writing semantic HTML with the right tags and right attributes? - **Semantic tags**: Use heading tags for titles, button tags for interactive elements, list tags for sequential elements, and so on. Don't use `
`s for everything! - **Heading hierarchy**: Ensure heading tags have a hierarchy and there's not more than one `

` in the DOM. -- **Interactive elements**: Use `