Skip to content

Latest commit

 

History

History
104 lines (92 loc) · 8.12 KB

dev-log-faq-repeat.md

File metadata and controls

104 lines (92 loc) · 8.12 KB
title tags created modified
dev-log-faq-repeat
dev
faq
repeat
2021-02-27 14:40:13 UTC
2021-03-29 19:17:20 UTC

dev-log-faq-repeat

guide

  • 大量配置项的处理
    • webpack
    • vscode

How to autosave small changes to big settings file without lag?

  • Provided that you want to keep the model with a multi-MB settings file, the most reasonable solution would be to use atomic writes to avoid the problem of the app being quit in the middle of a save.
  • Assuming your file is called settings.json, atomic writes would work something like this:
    • App decides to update settings, starts writing to a temporary file (to avoid overwriting the existing file halfway), say settings.json.tmp-1482198169 (1482198169 being current unix timestamp).
    • Once writing to settings.json.tmp-1482198169 is complete, copy the current settings.json to settings.json.bak.
    • Rename settings.json.tmp-1482198169 to settings.json, overwriting the old one.
  • The basic idea is to construct a process where you always have a valid copy of settings.json, so it's only replaced with a complete copy.
  • npm has a number of implementations of this, like this one. I'd recommend you try one of those instead of writing your own, since any bugs in the implementation of the atomic write dance could cause you data loss, and it's tricky to get everything right when dealing with asynchronous code.
    • https://github.com/npm/write-file-atomic
    • Write files in an atomic fashion w/configurable ownership
    • This is an extension for node's fs.writeFile that makes its operation atomic and allows you set ownership (uid/gid of the file).

is JSON.parse faster than declaring an object literal

  • The cost of parsing JSON

    • Because the JSON grammar is much simpler than JavaScript’s grammar, JSON can be parsed more efficiently than JavaScript.
    • This knowledge can be applied to improve start-up performance for web apps that ship large JSON-like configuration object literals (such as inline Redux stores).
    • Instead of inlining the data as a JavaScript object literal, it can be represented in JSON-stringified form, and then JSON-parsed at runtime
    • As long as the JSON string is only evaluated once, the JSON.parse approach is much faster compared to the JavaScript object literal, especially for cold loads.
    • A good rule of thumb is to apply this technique for objects of 10kB or larger — but as always with performance advice, measure the actual impact before making any changes.
    • At small-scales, JSON.parse is not faster than using object-literals in JavaScript.

  • ref

web app running in webview vs browser

  • android WebView

    • In most cases, we recommend using a standard web browser, like Chrome, to deliver content to the user.
    • WebView objects allow you to display web content as part of your activity layout, but lack some of the features of fully-developed browsers.
    • A WebView is useful when you need increased control over the UI and advanced configuration options that will allow you to embed web pages in a specially-designed environment for your app.

  • What is the engine of Android native browser?

  • Starting with Android 4.4 KitKat, Google has begun licensing Google Chrome (a proprietary software) separately from Android, but usually bundled with (what most device vendors did).

  • Android 4.4 includes a completely new implementation of WebView that's based on Chromium 30.

    • The new Chromium WebView is included on all compatible devices running Android 4.4 and higher.

  • Starting with Chrome version 51 on Android 7.0 and above, the Chrome APK on your device is used to provide and render Android System WebViews.

    • You can choose your WebView provider by enabling Developer Options and selecting WebView implementation.
    • multiprocess - Starting with Chrome version 51 in Android 7.0, WebView will run web content in a separate sandboxed process when the developer option Multiprocess WebView is enabled.

配置项过多时，如何处理更好，特别是针对组件或应用

  • tips

    • search: component too many props/options
    • Too many options = bad software.

  • 参考

    • vscode的settings页面
    • tsconfig的配置options页面
    • webpack的配置
    • css属性的类别和属性值的指定

  • 惯例优先原则/约定优于配置(convention over configuration)

    • 提供合理的默认值
    • opinionated的另外一个同义词是Convention over configuration，或者coding by convention

  • 拆分出弱耦合的小组件，然后组合小组件

  • 将部分紧密相关的配置项组合成一个大对象作为一个大的配置项，还要考虑方便替换该大配置对象的默认值

    • group by features
    • 类似component的variant属性，设计目的就是一次修改多个值

  • 利用custom hooks，将配置项参数作为函数的参数，而不是组件自身的参数

    • 也称为 state reducer pattern

  • It has too many configuration options and lacks configuration-by-convention dependency injection, one needs to look up all the services

  • A component with 500+ possible variants feels too much imho.

    • 本次讨论没有提出解决方案
    • If I’ve learned anything that past two weeks of focusing on standing up a library quickly it’s to not over-complicate variants or have too many of them for a single component. It’s not useful to force people to waste time parsing a ton of options in a bunch of select inputs.
    • I think this might be true for a lot of components, but a button in a reasonably complex design system? That's easily 500+ (1000+ depending on complexity) variations in the code component. How are you all doing this? Split by size (or w/e), even if that's not true in code?
      • <Button> props:
        • Size (several)
        • With icon (left or right)
        • Prominence (primary, secondary, tertiary, etc)
        • Visual style (default, success, danger, brand, etc—we had a lot lol)
        • Automatic width vs sized to container
        • Some others I'm missing heh

  • What do you get when you put too many props on a component instead of breaking it into smaller components? Prop soup

    • if you want the most flexibility, compound components are the way to go imo.
    • It allows you to create a wrapper component where you can pass in an object like you're saying AND you can create custom functionality elsewhere when you need it.

  • Hick’s Law predicts that the time and the effort it takes to make a decision increases with the number of options.

    • The more choices, the more time users take to make their decisions.
    • Trello's 3rd signup step has a dropdown with 15 options.
    • That makes it hard to pick one:
    • In a travel booking app like Airbnb, having too many options can lead to a paradox(矛盾的人/事) of choice (and a churn!):
    • Duolingo's list of lessons can sometimes be overwhelming
    • Zapier showed too many navigation links during their upgrade flow which distracts you from crucial checkout steps
    • Find an area where you have a lot of options or a lot of repetitions.
    • Try to either reduce the number of options or find ways to hide items.
    • If you can't minimize the options, try to put them in an easily skimmable order and make sure the items are familiar; else, it won't work.

  • ref