3 ms·

The solution to the button problem is obviously to intercept the call to the underlying API that draws the button. Ideally, by having a generic interface so tha

by GuB-42 2y ago

The solution to the button problem is obviously to intercept the call to the underlying API that draws the button. Ideally, by having a generic interface so that you can change the "color override" behavior at runtime. It means that in the future, all you have to do will be to specify your behavior in a JSON file that is dynamically loaded. You can also leverage the already present JS interpreter to specify rules (keep things simple, we don't want to have another domain specific language). To make the code more testable, the JSON file reader will be abstracted away and "mockable".

graypegg 2y ago
Cue the dialog configuration service, which will provide dynamic dialog configuration JSON files. The dialog configuration service will then need to communicate with the colour token service, which will be the single source of truth for the primary and secondary colour according to the current theme, so the dialog configuration service should only be concerned with the token representing the meaning it needs to communicate. And of course, the colour token service will need to adapt to the device's detected ambient brightness level, so the colour token service should probably apply a luminosity transform as suggested by the ambient lightness service... but that math can get rather complex so I think I'll stand up a new colour transformer instead which can handle that along with hue shifting, just in case our brand colours all change by the same relative hue-degrees on a normalized sRGB colour wheel all at the same time. Good talk team, we got a road map!
- disqard 2y ago
  ...and when the PM asks "why has this taken 3 years?", you explain on a whiteboard: https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ