feig: tweaks
This commit is contained in:
Yangshun
parent
233fb80deb
commit
937cb12529
|
|
@ -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",
|
||||
|
|
|
|||
|
|
@ -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 `<div>`s for everything!
|
||||
- **Heading hierarchy**: Ensure heading tags have a hierarchy and there's not more than one `<h1>` in the DOM.
|
||||
- **Interactive elements**: Use `<button>` for elements that require interaction. Resist adding click handlers to `<div>` and `<span>`s.
|
||||
- **Interactive elements**: Use `<button>` for elements that require interaction. Do not add click handlers to `<div>` and `<span>`s, that's a huge red flag and shows a lack of thought for accessibility.
|
||||
|
||||
### Forms
|
||||
|
||||
|
|
|
|||
|
|
@ -10,21 +10,21 @@ social_title: 用户界面问题备忘单 | 前端面试手册
|
|||
|
||||
## 一般
|
||||
|
||||
* **分解问题**：将问题分解为相互构建的阶段/里程碑，并逐步编写代码。
|
||||
* **经常测试**：在完成每个功能后在浏览器中测试 UI，以便您可以尽早发现错误。尽早发现的错误更容易修复。在继续下一个功能之前，请确保当前功能正常工作。
|
||||
* **如果可能，使用 JavaScript 框架**：如果您选择使用 Vanilla JavaScript 构建复杂的 UI，您的生活将会非常艰难，因为代码会变得非常冗长和混乱。我们建议尽可能使用框架构建应用程序和游戏。
|
||||
* **提前思考并相应地计划**：考虑一下您的面试官可能要求您接下来添加哪些功能。以一种易于添加新功能的方式设计您的代码。
|
||||
* **分解问题**: 将问题分解为相互构建的阶段/里程碑，并逐步编写代码。
|
||||
* **频繁测试**: 在完成每个功能后，在浏览器中测试 UI，以便尽早发现错误。 尽早发现的错误更容易修复。 在继续下一个功能之前，请确保当前功能正常工作。
|
||||
* **如果可能，使用 JavaScript 框架**: 如果您选择使用 Vanilla JavaScript 构建复杂的 UI，您的生活将会非常艰难，因为代码会变得非常冗长且混乱。 我们建议尽可能使用 JavaScript 框架/库（例如 React、Vue、Angular 等）构建应用程序和游戏。
|
||||
* **提前思考并相应地计划**: 考虑您的面试官可能要求您接下来添加哪些功能，方法是借鉴您在构建实际应用程序、使用库或练习面试问题方面的经验。 以一种易于添加新功能的方式设计您的代码。 大部分时间，您会被要求将您的 UI 组件化，以便可以在页面上显示多个组件实例——模块化并避免依赖全局状态或污染全局命名空间。
|
||||
|
||||
## 组件组织
|
||||
|
||||
您如何组织代码？
|
||||
|
||||
* **采用 [容器/呈现模式](https://www.patterns.dev/posts/presentational-container-pattern/)**：为了实现良好的解耦，渲染代码应该与数据源无关。将组件分成一个提供数据的外部组件和一个根据数据渲染视图的内部无状态组件。这使得视图可以轻松地从本地组件/应用程序状态切换到从网络加载的数据，反之亦然，您只需更改外部组件，内部组件即可按原样使用。
|
||||
* **将应用程序分解为子组件**：如果 UI 有多个部分，请将 UI 分解为更小的组件，并确定每个组件所需的 props/state。
|
||||
* **最小的 API 表面积**：不要将多余的数据传递给不需要它们的内部组件。
|
||||
* **组件实例化**：当被要求构建 UI 组件时，定义 API（通常是函数）以允许创建组件的多个独立实例以及可配置的选项和默认值。避免编写代码（例如，依赖全局变量），这会阻止创建单独的 UI 组件实例。
|
||||
* **Vanilla JavaScript**：创建一个接受 DOM 元素（容器元素）和选项对象的函数。在函数中，您可以动态创建 DOM 元素并附加到容器元素。组件 API 的另一个灵感来源是 [jQuery UI](https://jqueryui.com)，但它依赖于 jQuery。
|
||||
* **其他 JavaScript UI 框架**：大多数现代 JavaScript UI 框架（如 React）默认情况下会迫使您从组件的角度进行思考。
|
||||
* **采用 [容器/表现模式](https://www.patterns.dev/posts/presentational-container-pattern/)**: 为了实现良好的解耦，渲染代码应该与数据源无关。 将组件分成一个提供数据的外层和一个根据数据渲染视图的内部无状态组件。 这使得视图可以轻松地从本地组件/应用程序状态切换到从网络加载的数据，反之亦然，您只需更改外部组件，内部组件即可按原样使用。 这种分离也方便了表现组件的测试，因为所需的数据可以很容易地被模拟。
|
||||
* **将应用程序分解为更小的组件**: 如果 UI 有多个部分，将 UI 分解为更小的组件，并确定每个组件所需的 props/state。
|
||||
* **最小的 API 表面积**: 不要将多余的数据传递给不需要它们的内部组件。
|
||||
* **组件实例化**: 当被要求构建 UI 组件时，定义 API（通常是函数）以允许创建组件的多个独立实例以及可配置的选项和默认值。 避免编写阻止创建多个 UI 组件实例的代码（例如，依赖全局变量）。
|
||||
* **Vanilla JavaScript**: 创建一个接受 DOM 元素（容器元素）和选项对象的函数。 在该函数中，您可以动态创建 DOM 元素并附加到容器元素。 组件 API 的另一个灵感来源是 [jQuery UI](https://jqueryui.com)，但它依赖于 jQuery。
|
||||
* **其他 JavaScript UI 框架**: 大多数现代 JavaScript UI 框架（例如 React、Vue、Angular）默认情况下会迫使您从组件的角度进行思考。
|
||||
|
||||
## 状态设计
|
||||
|
||||
|
|
@ -32,10 +32,9 @@ social_title: 用户界面问题备忘单 | 前端面试手册
|
|||
|
||||
面试中的大多数 UI 问题都需要状态，并且良好地设计状态至关重要。
|
||||
|
||||
* **确定 UI 中所需的最少状态**：状态越小，代码就越容易阅读和理解 -> 出现错误的概率越低。
|
||||
* 确定基本状态与派生状态。派生状态是可以从基本状态计算的状态。
|
||||
* **分离渲染代码与数据管理代码**：使 UI 成为数据的函数，并将代码分成两组（渲染代码和数据管理代码），以提高可读性。如果您使用 JavaScript 框架（如 React），您或多或少会被迫这样做。
|
||||
* **对复杂的状态交互使用状态-reducer 模式**：如果问题需要许多状态字段，并且某些操作需要同时更改多个字段，请使用 [reducer 来合并状态更新逻辑](https://beta.reactjs.org/learn/extracting-state-logic-into-a-reducer)。状态-reducer 模式最初由 Redux 推广，它鼓励您确定 UI 的状态、可以采取的操作以及如何将操作与状态结合起来以推导出下一个状态。如果您使用 React，您可以通过 [`useReducer` React hook](https://reactjs.org/docs/hooks-reference.html#usereducer) 实现此模式。Redux 通常对于面试来说是过度的，而 `useReducer` 应该足够了。
|
||||
* **确定 UI 中所需的最少状态**: 状态越小，代码就越容易阅读和理解 -> 出现错误的概率越低。 确定基本状态与派生状态。 派生状态是可以从基本状态计算出来的状态。 通过即时派生状态，您可以减少状态值不同步的可能性。
|
||||
* **分离渲染代码与数据管理代码**: 使 UI 成为数据的函数，并将代码分成两部分（渲染代码与数据管理代码），以提高可读性。 如果您使用 JavaScript 框架（例如 React），您或多或少会被迫这样做。
|
||||
* **对复杂的状态交互使用状态-reducer 模式**: 如果问题需要许多状态字段，并且某些操作需要同时更改多个字段，请使用 [reducer 来合并状态更新逻辑](https://beta.reactjs.org/learn/extracting-state-logic-into-a-reducer)。 状态-reducer 模式最初由 Redux 推广，它鼓励您确定 UI 的状态、可以采取的操作以及如何将操作与状态结合起来以推导出下一个状态。 如果您使用 React，您可以通过 [`useReducer` React hook](https://reactjs.org/docs/hooks-reference.html#usereducer) 实现此模式。 Redux 通常对于面试来说是过度的，而 `useReducer` 应该足够了。
|
||||
|
||||
[React 的](https://beta.reactjs.org) 关于 [“管理状态”](https://beta.reactjs.org/learn/managing-state) 的文档是关于如何正确设计和使用组件状态的绝佳资源。提到的一些想法并非特定于 React，可以应用于任何 UI 框架。
|
||||
|
||||
|
|
@ -48,11 +47,11 @@ social_title: 用户界面问题备忘单 | 前端面试手册
|
|||
|
||||
## HTML
|
||||
|
||||
您是否使用正确的属性编写语义 HTML？
|
||||
您是否使用正确的标签和正确的属性编写语义 HTML？
|
||||
|
||||
* **语义标签**：使用标题标签表示标题，使用按钮标签表示交互元素，使用列表标签表示顺序元素，等等。不要对所有内容都使用 `<div>`！
|
||||
* **标题层次结构**：确保标题标签具有层次结构，并且 DOM 中只有一个 `<h1>`。
|
||||
* **交互元素**：对需要交互的元素使用 `<button>`。 避免向 `<div>` 和 `<span>` 添加点击处理程序。
|
||||
* **语义标签**: 使用标题标签表示标题，使用按钮标签表示交互元素，使用列表标签表示顺序元素，等等。 不要对所有内容都使用 `<div>`！
|
||||
* **标题层次结构**: 确保标题标签具有层次结构，并且 DOM 中只有一个 `<h1>`。
|
||||
* **交互元素**: 使用 `<button>` 表示需要交互的元素。 不要向 `<div>` 和 `<span>` 添加点击处理程序，这是一个巨大的危险信号，表明缺乏对可访问性的考虑。
|
||||
|
||||
### 表单
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@
|
|||
"e0d8bb38",
|
||||
"4c266b7c",
|
||||
"ede597ea",
|
||||
"ed1196e3",
|
||||
"9e022488",
|
||||
"a751801d",
|
||||
"55890346",
|
||||
"d7976b37",
|
||||
|
|
@ -60,7 +60,7 @@
|
|||
"e0d8bb38",
|
||||
"4c266b7c",
|
||||
"ede597ea",
|
||||
"ed1196e3",
|
||||
"9e022488",
|
||||
"a751801d",
|
||||
"55890346",
|
||||
"d7976b37",
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ Be familiar with these web development concepts:
|
|||
|
||||
## User interface coding interview rubrics
|
||||
|
||||
User interface coding interviews have similar rubrics as to JavaScript coding interviews as both involve coding in the front end domain. However, user interface coding questions will have even more emphasis on domain expertise and the various front end topics.
|
||||
User interface coding interviews have similar rubrics as JavaScript coding interviews as both involve coding in the front end domain. However, user interface coding questions will have even more emphasis on domain expertise and the various front end topics.
|
||||
|
||||
- **Problem solving**: Use a systematic and logical approach to understanding and addressing a problem. Break down the problem into smaller independent problems. Evaluate different approaches and their tradeoffs
|
||||
- **Software engineering foundation**: Familiarity with data structures, algorithms, runtime complexity analysis, use of design patterns, design solution with clean abstractions
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ social_title: 破解用户界面问题 | 前端面试手册
|
|||
|
||||
## 用户界面编码面试标准
|
||||
|
||||
用户界面编码面试与 JavaScript 编码面试具有相似的标准，因为两者都涉及在前端领域进行编码。 然而，用户界面编码问题将更加侧重于领域专业知识和各种前端主题。
|
||||
用户界面编码面试与 JavaScript 编码面试的评分标准类似，因为两者都涉及前端领域的编码。 然而，用户界面编码问题将更加侧重于领域专业知识和各种前端主题。
|
||||
|
||||
* **解决问题**：使用系统和逻辑的方法来理解和解决问题。 将问题分解为更小的独立问题。 评估不同的方法及其权衡
|
||||
* **软件工程基础**：熟悉数据结构、算法、运行时复杂度分析、设计模式的使用、使用干净的抽象设计解决方案
|
||||
|
|
|
|||
Loading…
Reference in New Issue