The Import on Interaction Pattern
09 Jan 2021The Import on Interaction Pattern
tl;dr: lazy-load non-critical resources when a user interacts with UI requiring it
The Import on Interaction Pattern
tl;dr: lazy-load non-critical resources when a user interacts with UI requiring it
In CSS, adjacent margins can sometimes overlap. This is known as “margin collapse”, and it has a reputation for being quite dastardly.
A nice and clear explanation of how CSS margins collapse with interactive demos. Certainly calrified a few things for me!
Build Production Design Systems Faster
Storybook began with a simple goal: help developers build UI components and their key states. This is the easiest, most efficient way to think through component hierarchies
However, the bar on UI development has also been raised. In 2020, it’s not enough to provide great tooling for building and testing components. Today’s modern frontend teams also need to document and package their components into reusable design systems.
Storybook is one of my favorite tools for UI-first development, and I’m looking forward to checking out their latest 5.3 release with MDX doc capabilities
Migrating From Flow to Typescript: Why? How? Worth It?
When I arrived at Inato, the codebase was written in ES6. Then, we added some robustness with Flow. It helped us perform major refactors and lower our bug count. We were happy… until problems showed up.
I’ve been using Flow for a bit over 3 years now on the same project. I have had experience with typed languages before (.Net C#, Java) so it was not an entirely new thing, but I admittedly found many annoyances with types in these languages and I was always eager to use new features in a language (C#’s var for one) to reduce the overhead. I found it annoying that the compiler would complain if I told it the wrong type, but tell me what type it should be. I mean if it knows what it is, how about it just dealt with it and stop bothering me? 🙄
So coming to and environment that used typed javascript (Flow) I was skeptical at first… but it quicly became clear that there were whole classes of bugs that didn’t exist because I had the safety of a type system… ensuring I wasnt passing the wrong things or edge cases were properly covered (looking at you null or undefined 🤨)
But 3 years on and supporting Flow in our still growing codebase has been wearing us down. Third party library support is… spotty. Updates to flow-bin have lead to a slew of new errors (aka newly supported cases) with little help from the error messages or library typedefs to previously “happy” codebases (redux connect and @FlowFixMe like cookies and cream), to the point that we are wondering “is it all worth it?”
Has TypeScript won the war of developer mindshare? It sure is time for us however, and I’m relieved to see we are not the only ones.
Base Web is a foundation for initiating, evolving, and unifying web applications. It’s an open source toolkit of React components and utilities that align with the Base Design System–essentially, the designs translated into code. The project is engineered to be reliable, accessible, and extensively customizable.
We have been using Material-UI for our base component library but Uber’s open-source alternative is going to get serious consideration for my next projects. It looks to be fairly comprehensive in ots components, and I like that the style choices are very neutral. A strong customization API is high on the list of needs for any component library I’m evaluating.