1. JSON.Stringify
Quite alright now
2. Autocomplete
a) System Architecture
- React View Component
- Controller - Cache
- Server
b) API Design
- input: String, output: Array
c) Consider Requirements
- debounce? QPS allowed on BE?
- how often do you want to refresh data?
- offline error
- global? Local? Localised content?
d) Code / Test
- limit to 10 results. Too many choice can be confusing UX
- Debounce duration to test with UAT and Designers for optimal UX. 300 - 500ms perhaps.
- search string put as the cache key, case insensitive.
- cache on localstorage, or indexedDB if possible, since search space is large.
- abstract able component, might use this component on other pages.
- offline error perhaps a bar at top of the page in red, showing the error. The search can show loading ui, and poll every second for the answer.
e) Optimise
- accessibility short keys
- button click size
3. System Design in General
Reading this UI guide, seems that everything is quite clear. The only thing that's abit obtuse is accessibility.
They recommended a course here but let's revisit that it we have time.
- this page actually has a list of interesting possible questions and areas to focus on
4 & 5. Leetcode JS Questions
Doing some of these, I think Leetcode constrains the problems very well compared to GreatFrontEnd. The latter challenges us to consider more data-types (strings, number, null, object, array), while Leetcode is very definitive. GFE also helps in trying to understand this and prototypical inheritance of the sorts, or like extending a prototype to have new functions. Leetcode just create a typical JS function, which is way easier to do.
This func.apply vs func.call vs () => {} still gets me. I guess I should study abit and then apply it to some questions tomorrow.
This StackOverflow post seems to summarise it nicely. In essence, anything that needs to use this or arguments cannot use arrow functions. And another article on bind
Top comments (0)