Forem: Vladimir Klepov

I conducted 60 interviews in 2 months — here's what I learned

Vladimir Klepov — Sat, 06 Jan 2024 00:00:00 +0000

It's hard to believe, but, starting mid-october 2023 I conducted 60 technical interviews and hired 10 people into our team. It's been extremely tiring: around 80 hours of active interviewing, plus writing interview reports, plus screening CVs and take-home assignments, plus onboarding new members — all while doing my normal work stuff. Still, I feel like I learnt a lot in the process — things that would help me as a candidate in the future, and might help you land your next job.

Note that I'm a fairly relaxed interviewer, and, as an internal startup of a large tech company, we generally have a more humane hiring process, so your mileage may vary. Still, I've done my best to pick the tips that I feel are universally applicable.

Here are nine insights I took out of this experience, in no particular order:

Be generous with your "expected income".

Say you're a solid higher-middle engineer, and you ask for a senior salary. My thought process: OK buddy, it's a bit more than reasonable now, but I won't have to fight for your promotion 8–12 months from now when you get there, and I don't have to spend another 12 hours of my own time (and leave my team understaffed for another few weeks) looking for a real hardcore senior, so I'll let you have it. Now suppose you ask for a junior salary. It's suspicious — why is your bar so low? Is there someting about your work performance you're not telling us? So, do your research on reasonable salaries for your level of experience, and aim slightly above that.

Ask the right questions.

I always leave time for the candidate to ask me questions — obviously, this lets the candidate probe what it's like to work at our team, but it's also the best opportunity for me to learn what really matters to the candidate. I've never been much of an asker myself, but now I see that "Thanks, I have no questions" does not look good — if anything, it paints you as someone who doesn't care. Here's a short list of good questions:

What does the daily work in this role look like? Harmless.
What features are you building next? Caring about the overall product, nice. Sometimes the answer is "I can't disclose this secret", but not that often.
Anyting about processes or team structure: how many people are on the team? How often do you release? What regular meetings do you have? Interested in organization, might want to be a team lead someday, great.
Anything tech-related: which framework do you use? Why did you pick framework X? How do you test your app? Especially suitable for junior- to middle developers who are most involved in hands-on work.
What kind of tasks do you see me doing? Again, just a good neutral question, because responsibilities for any role differ wildly between companies.
What growth / promotion opportunities does this position have? Cool trick, flipping the feared "where do you see yourself in 5 years" question against the hiring manager.

Here are a few questions that are not very good:

Do you use jira and github? It's a minor detail, won't you be able to work with youtrack and gitlab?
Do you sometimes work late? Only if something breaks, but overall this question makes you seem a bit lazy. People on poor teams that routinely overtime aren't likely to answer this question honestly, at any rate.

Social skills matter.

I understand that not everybody is super outgoing, but if we already feel awkward 1 hour into our acquaintance, why work together — to feel awkward for months to come? Just a few tips anyone can follow:

Be energetic. You're tired, I'm tired, we're all tired of endless interviews. Are you just tired today, or generally always too tired to get anything done? I know it's easier said than done, but try and show me all the energy you have left.
Show respect. People enjoy being respected. Very easy one: you have a great product. Sounds like you have a great engineering culture. This is one of the most interesting interviews I've ever seen. Like, I know you don't necessarily mean that, but subconsciously I'm very pleased: "oh yes, I'm very proud of my interview process, thanks for noticing"

On a related note...

Provide conversation opportunities.

Q: Do you use TDD? Bad answer: "no". Good answer: "no, but I've heard of it. Interesting approach. Does your team use TDD?" Now you get to spend 5 minutes talking on your terms instead of being bombarded with random questions, and you come off as someone curious about stuff.

On another related note...

It's easy to hurt people.

People normally ask you about stuff because they care about it. So, again, the interviewer askning "do you use TDD?", presumably, likes TDD and uses it. So, the worst answer: "no, TDD sucks, it's pure waste of time for idiots." A rare interviewer might appreciate you having a strong opinion on a topic, but to most this just paints you as a jerk, kinda like "Here's a photo of my children — "I hate children, and yours are especialy horrible". Not smart.

Smart talk is not your friend.

Saying stuff like "our front-end guild evaluated several cutting-edge approaches to testing universal applications" only makes you seem smart if you can elaborate on that topic: what these approaches were, the pros and cons you found, what tradeoffs you made for your final decision. If you can't answer a follow-up question beside "we settled on jest, not sure why", it was better to stay away from that topic altogether. Related: "in code reviews, I always consider the optimality of the algorithm selected" (proceeds to estimate the time complexity of comparison-based sorting as O(1). I never ask this unless the candidate boasts about her algo skillz).

Admit your mistakes.

Don't know an answer? Your code has a bug? It's always better to admit it and then try to come up with something at the spot than trying to talk your way out of it. Event loop? Sure thing, I'm an expert on loops. It's the way events are looped. Uses logarithmic weighing. Again, this makes you look like a candidate with big mouth and small hands. I have seen a couple of people who could talk their way out of any situation, but I honestly think with such skills you'd do better in a different line of work, like international relations, or selling financial services. Note that you really should give it your best shot — giving up at the first sign of trouble is not a good impression. If you genuinely have no idea — see conversation opportunity: "Event delegation? Tough luck, never heard of it. Would you tell me about it so that I learn something new today?"

Make yourself memorable.

It's hard to keep detailed profiles of 10 candidates in mind — after a good interview streak all I remember is the general impression (great / OK / horrible) and a few truly notable things. This guy worked for some crypto scam that went bust, that girl had a cute dog that was trying to eat the camera. The worst you can do is be a totally neutral candidate — we've had an interview, but I can't remember any details. So try and sneak some anecdote, or wear a silly scarf — something to remember. This point is especially important for intern / junior positions — online JS bootcamps do a good job of covering the basics, and it's really hard to differentiate these candidates. The memorable thing doesn't have to be professional, or even positive (even though it sure won't hurt) — your best bet would be some original personal project.

Ask for feedback on the spot.

Asking how you did at the end of the interview doesn't hurt. Yes, some interviewers will be hesitant to answer — at large companies, the feedback is normally sent through the recruiter, and you're never sure if sidestepping this process would get you into trouble. Besides, if the feedback is not complimentary, you're essentially asking for conflict at the spot, and people normally avoid conflict when possible. Still, it's a chance to adjust your expectations (if the interviewer says, looking you in the eyes, that you've done great, it's a good sign), and you might get actually useful tips that would probably get lost passing through the written report, and then through the non-technical recruiter.

I built Hippotable for in-browser data analysis

Vladimir Klepov — Wed, 27 Dec 2023 19:41:48 +0000

I'm happy to announce the first public release of Hippotable — a tool that lets you analyze data without leaving your browser, on desktop & mobile.

I often analyze small- to mid-sized datasets for work and for fun — e.g. to find out the distribution of a certain bug by platform, or calculate unique affected users. But what tools do I have to help me here?

Bash lets you uniq | wc -l — handy, but making advanced pipelines is hard.
Google sheets does the job, but struggles above 10K rows due to all the cruft, and using it for sensitive data such as personal budgets or user data is a no-no.
Python + jupyter + pandas is up to any data problem, but it's overkill for my simplistic use cases, and requires a lot of code.

So I set out to build a simple browser-based tool to do the job. Hippotable can:

Open CSV files up to 100 Mb in size.
Scroll though thousands of rows.
Filter and sort your data in real time.
Aggregate / groupby data to gain deeper insights.
🏗️ Build powerful data pipelines with multiple filter / aggregate steps.
Share results with CSV export.

It's also free and open source.

Example

Now, let me walk you through an example of analyzing an annotated movie dataset from kaggle. Let's start simple and see which countries, on average, make the best movies. Group by country, sort by average rating:

Hm, this looks like a selection of countries which happened to co-produce a decent film once, not that interesting. Let's try again, removing countries that have <10 movies:

Now that's unexpected! In case you're curious, lots and lots of bad films come from Italy:

Combining multiple filter and aggregation layers enables really powerful processing pipelines. For example, here are countries that were home to most great directors (see, not all is lost for Italy):

That's it for today! Give hippotable a try and star on GitHub to help spread the word. Join me next time to learn about the amazing tech I used to make this happen.

Meet banditypes — the smallest TypeScript validation library

Vladimir Klepov — Wed, 08 Mar 2023 21:04:35 +0000

I'm excited to announce banditypes — a new validation library for TS and JS. You may have heard of zod or superstruct — these great tools let you define a JS schema to validate objects, and automatically convert the schema to a TS type to avoid duplication. Well, banditypes does the same thing, but in 400 bytes!

Curious to learn how it can be so small? It boils down to three design principles:

Strict scope cutting. More full-featured validation libraries tell you what, exactly, failed validation. This feature had to go.
Export functions, not objects with methods, because functions tree-shake better. This is exactly why superstruct is already 3–5 times lighter than zod.
More extensibiltiy. If you cut features from the core, the users must be able to write the missing bits themselves.

And some more optimization on top:

Compile to modern JS. Gzip is good, but replacing function () with () => still saved 20 bytes!
Minimal API. Bye-bye literal(42), we have enums([42])
Gzip-aware code style. Gzip removes repetition, so you need to make different parts of code as similar as possible. Write Object once, repeat for free. Surprise: copy-pasting functions with minor changes is often smaller under gzip than proper code reuse.

I have published an article with a more in-depth explanation.

Banditypes is not a validation library for every use case, but it gains something from its minimal design, and was fun to build. Check it out on GitHub, and maybe even give it a spin in your next project!

I ditched Google analytics and went self-hosted

Vladimir Klepov — Sun, 12 Feb 2023 00:00:00 +0000

I love writing, and I also love data. When starting my blog, I integrated Google Analytics — it's free, easy to set up (just drop a few tags on the page), and that's what I knew back then. I did not enjoy it being run by a big corporation, but I was too lazy to research the alternatives, and then pay for them. But when Google announced sunsetting the current generation of analytics, and I had to take some action at any rate, I decided to pull the trigger and make a jump to an open-source alternative.

My analytics needs are quite simple, really:

See how many people read my articles, along with basic stats like session depth and duraiton, because this makes me feel good.
Filter by source to see which places work better for sharing my content.
Custom events, so that I see how design changes help me grow an audience (and this works as a cheap JS error tracker).
Data export would be nice — sometimes I play around with it in pandas.

In this article, I give compelling reasons to switch to self-hosted analytics. I share my research on seven open-source analytics tools so that you don't have to do it yourself. Then, I provide a quick tutorial to get up and running with plausible. Whether you're still on google analytics (or a comparable corporate tool like Meta pixel or Yandex metrica), or just considering adding analytics to your website, this will get you up and running in no time.

Why self-host your web analytics

I know that paying (either by subscribing to a paid hosted version or maintaining your own infrastructure) for something you can get for free needs justification. And in case on web analytics, you do get decent benefits for your buck:

Privacy — we all know google eats user data for breakfast, lunch and dinner. You "pay" for google analytics with your users' data. The tools we're discussing do not come from companies that run the internet, and don't have the same data collection motivation, so you do protect your user privacy by switching. You might argue "I like programming" is not the most private information, so let's move on to the less moral and more practical arguments.
Better data. Google analytics are blocked by most adblock tools, leaving you with incomplete data — some research suggesting figures around 43%. Switching to a less intrusive alternative gives you back the missing data, and more data means better insights with less effort.
Fuck big tech. My blog was basically excluded from google search in october 2022 for no reason, and I want revenge. Depriving google of my users' data is like a microbe bite, but it does feel good.

While not directly related to self-hosting or open source, most of the tools we discuss have extra desirable treats:

No cookies, so I don't have to worry about GDPR banners or whatever (even though some disagree). To be fair, I'm not 100% sure you absolutely need a banner whenever you have any cookie, but I'm not a lawyer and no cookies sounds like no problems to me.
Simpler interface. This does sound like a made-up justification for limited functionality, but I honestly see this as a win for a casual analytics user like myself.
Smaller JS footprint = better website performance. Google Analytics is famously around 50KB / 21KB gzip of JS, while most tools we discuss have scripts under 2KB. It's not a huge deal, as a tracking script does not block anything and is cached, but a pleasant bonus. In theory, this lets you catch a few events that occurr soon after the first page load.

Now, is self-hosting the anallytics worth the trouble of setting up and maintaing the infrastructure? I think the answer is yes, and here's why:

Yet more privacy. When sending your user data to any third party, you're counting on their good will. If your data goes to your own server, it just stays there. If you're extra paranoid, you can ban outgoing traffic from the analytics container, or implement any other security measures.
Yet better data collection. Some privacy protection tools do restrict connections to well-known analytics hosts. Sending data to your own domain makes blocking your tracker much harder, because a domain blacklist won't cut it any more.
Price. As we'll see, you can self-host analytics for around 6$ a month, which is cheaper than the paid analytics services I've seen, and this price will not auto-escalate if you suddenly have a traffic spike.
Data ownership. Your historic data lives on your server, and you're free to export it regardless of any decisions the maintainers of the tools make. Not every tool on our list has easy export, but nothing stops you from a DB dump in the worst case.
No vendor lock-in. With your data available, you can (in theory) migrate to any other analytics service if you change your mind. Again, not all the tools can import data, but some can.
Future-proof. The company developing your tool of choice goes out of business, switches to closed-source, or makes a big update that requires you to reconfigure everyting from scratch? No worries, you can just stay on your current version as long as you please.

This should be enough to convince even the most skeptical readers that self-hosted analytics instance is worth it. Now, what tools are available for the job, and which one should you pick?

Open-source web analytics tools, an overview

When it comes to open-source analytics tools, we have three top-tier choices: matomo, plausible and umami.

Matomo is the most established tool in the game (been doing it since 2011). I have personally seen it used by huge compaines, and people were pleased with it (it was called piwik back then). It's the closest alternative to google analytics in terms of features — you get customizable dashboards, integrations (ecommerce, website builders, multiple search providers), alerts, plugins, exports and what not. It even has iOS / android SDKs. But the truth is, I don't need all these extra features, I don't want to pay for it (in terms of a larger tracking script and more complex dashboards) and I'd be perfectly happy with something simpler, which brings us to...

Plausible, in contrast, offers a stripped-down analytics experience with only the essential metrics — page views, bounce. duration, source, device, location by default. It's cookie-free and features a tiny script (claims to be "< 1KB", but it's 1.6KB on my page). Any custom events can be sent via JS API. The docs are top notch, the docker set-up is straightforward, and you can import and export CSV data as you please. I'm loving the feature set, and this is what I ultimately went with. One valid criticism of plausible is that it's slightly convoluted, featuring two databases and an elixir server, which makes it pretty hard to set up without docker, but I don't mind it.

Umami is another "simple analytics" tool. I find it extremely similar to plausible — same minimal dashboard, same cookie-free tracking, same tiny script (1.6KB gzip). It launched in 2020 with great hype, but plausible quickly caught up. As of 2023, umami still lacks data import from GA, and only supports export via DB dump — plausible can do both easily. I also prefer plausible docs. Umami has only one DB, and can run as a raw node service. Overall, it's a viable choice, and competition is always good.

For historical reference, fathom was among the first privacy-focued trackers. It has since re-launched as a paid product, freezing development on the open-source version. The fact that you can still install and use it demonstrates my point on "suture-proofness" in action. I'd prefer something that's actively devloped, and I see no reason to pick it over the tools mentioned above.

Among the lesser-known tools I found these three to stand out from the competition:

Offen (dope landing page design!) is built around "fairness". Your visitors must give explicit consent to data collection, and can view or delete their data at any time. On the practical side, it comes with auto-renewing SSL out of the box, which is nice. I'm not against consent, but I have personally developed popup blindness, and I'm afraid the users will just scroll with the banner hanging around. Sadly, it can't track custom events (clicks, forms, etc) as of 2023, and has no import / export (presumably by design).
Goatcounter can run without JS via a tracking pixel (but comes with full JS version, too). Extras: CSV export, API access, good docs, signle-binary deploy, and the name is quite funny. You might say the UI is dated, but I'd call it hacker-themed.
Ackee comes with extra anonymization and features a GraphQL API that allows you to import / export data as needed and build custom integrations or dashboards.

Then, of course, you can just take a generic log analyzer (grafana, graylog, goaccess) and throw any data you wish there. You get more flexibility, but there are no precofigured views for common web stats, and you must write the actual tracking logic (both JS and the endpoint) yourself. We track product metrics via a log aggregator at work as it lets us trace problems to back-end issues, but I wouldn't take this path for a simple website.

Ultimately, I picked plausible because of its minimal approach, complete feature set (mainly data import / export) and great docs. However, all the tools on my list have their strenghts, and you can pick whichver you prefer, or even try a few before commiting. Here's a flowchart with some things that might influence your decision:

Up and running

Before we get started, you'll most certainly need two pieces of infrastructure:

A server — fair enough, you need a hosting to self-host anything. I use an entry-level linode for $5 a month, which is a typical price. With your average blog traffic this leaves room for other services — OpenVPN server, Gitea or whatever you wish.
A custom domain name. GitHub can't proxy some traffic from username.github.io to your analytics server, and HTTPS won't work on a raw server IP without a domain name. You can get one starting at $5 a year (more for a decent TLD, make it $20). I heard porkbun suggested. You are not obliged to use this domain for your website (even though GH pages support that), so something shady like fk12sdj1244.cyou works if you wish.

With that in place, we can set up our plausible instance. I'll make it quick, since there already is a tutorial by Mansoor, and the docs do a decent job:

Install docker.
Start plausible: clone the repo, edit config, and docker-compose up -d the service (see docs). If this worked, you can access the UI at http://your.ip.1.1:8000
You can't send analytics from your HTTPS website to an HTTP endpoint, so there's more work.
Go to your DNS settings, come up with an analytics subdoiain (like an.you.io) and add server IP to the relevant A/AAAA record. Plausible can not live on a /path, it needs its own subdomain. Success = the UI is live on http://an.you.io:8000
Now we need a reverse proxy for SSL termination. I went for a full-dockerized setup with nginx-proxy container. Set VIRTUAL_HOST in plausible-conf to enable discovery, append nginx-proxy to docker-compose.yml, restart, and you should be able to access analytics at http://an.you.io. Un-exposing the port 8000 at this point won't hurt.
Now, the actual SSL certificates. nginx-proxy has an acme-companion container that manages letsencrypt certificates for you. Add it to your docker-compose.yml along with all the extra volume declaraions, and you're all set — https://an.you.io
It's time to add https://an.you.io/js/script.js script to your website and watch the data flow.
The most painful step is importing historical data from google analytics (thanks google, it is possible). Here are the docs to help you. Took me an hour of Google Cloud and SSO suffering, but it all worked out fine.

Et voila, you're self-hosting your analytics. No need to involve google nay more. The same process applies to any dockerized setup with minor adjustments, not just plausible.

Self-hosting your website analytics comes at a cost — to be precise, around $7 a month for hosting and the domain, but you can use the same infrastructure for other tasks and you get quite a few benefits in doing so:

User privacy — no data sent to any third parties.
Less missing data — your own domain is unlikely to be adblocked.
Data ownership — you can always export historic data and move to another tool (worst case — via SQL dump).
Future-proofness — even if the developer goes out of business, your instance stays with you.
Price (when compared to hosted alternatives) — you can easily run analytics for under $7/mo, including a custom domain, while hosted solutions start at $9.
Most importantly, it's one small step that we, as a content creators, can take to make a dent in corporate monopoly.

Most privacy-focused analytics tools also feature no cookies (aka fewer legal concerns, but not like in legal advice etc.), simpler interface, and smaller tracking JS (both at the expense of less data).

We examined seven open-source analytics tools that you can self-host. Here they are, in order of my preference:

Plausible is a minimal analytics solution with enough features for me: custom events, API, GA import, CSV export. Great docs!
Umami is very similar to plausible. I prefer import / export and docs on plausible, but umami has slightly better mobile UX. Close call.
Goatcounter is a hacker-style tracker. Runs as a single binary, supports no-JS tracking via pixels or log imports. UI choices are divisive.
Matomo is a well-established platform with lost and lots of features you probably don't need.
Ackee comes with a GraphQL API and nice UI.
Offen is conceptual: it requires explicit consent, and users can view their data. How well this works in practice remains to be seen. Some features are missing — most importantly, custom event tracking.
Fathom is not bad, but I can't recommend it since the development of free version has been shut down.

Finally, I showed you how to install and integrate your own plausible instance, along with HTTPS.

Now it's your turn to self-host your analytics and say good-bye to google.

Making sense of TypeScript using set theory

Vladimir Klepov — Mon, 23 Jan 2023 00:00:00 +0000

I've been working with TypeScript for a long long time. I think I'm not too bad at it. However, to my despair, some low-level behaviors still confuse me:

Why does 0 | 1 extends 0 ? true : false evaluate to false?
I'm very ashamed, but I sometimes confuse "subtype" and "supertype". Which is which?
While we're at it, what are type "narrowing" and "widening", and how do they relate to sub/supertypes?
If you want an object that satisfies both { name: string } and { age: number }, do you & or |? Both make some sense, since I want a union of the functionality in both interfaces, but I also want the object to satisfy left & (and) right interfaces.
How is any different from unknown? All I get is imprecise mnemonics like "Avoid Any, Use Unknown". Why?
What, exactly, is never? "A value that never happens" is very dramatic, but not too precise.
Why whatever | never === whatever and whatever & never === never?
Why on earth is const x: {} = true; valid TS code? true is clearly not an empty object.

I was doing some research on never, and stumbled upon Zhenghao He's Complete Guide To TypeScript’s Never Type (check out his blog, it's super cool!). It mentions that a type is just a set of values, and — boom — it clicked. I went back to the basics, re-formulating everything I know about TS into set-theoretic terms. Follow me as I:

Refresh my knowledge of set theory,
Map TS concepts to their set counterparts,
Start simple with booelan, null and undefined types,
Extend to strings and numbers, finding some types that TS can not express,
Jump into objects, proving my assumptions about them wrong,
Finally gain confidence writing extends caluses,
And put unknown and any where they belong.

In the end, I solve most of my questions, grow much cozier with TS, and come up with this brilliant map of TS types:

Set theory

First up, a refresher on set theory. Feel free to skip if you're a pro, but my algebra skills are a bit rusty, so I could use a reminder of how it works.

Sets are unordered collections of objects. In kindergarten terms: say we have two apples aka objects (let's call them ivan and bob, shall we?), and some bags aka sets where we can put the apples. We can make, in total, 4 apple sets:

A bag with apple ivan, { ivan } — sets are written as curly brackets with the set items inside.
Similarly, you can have a bag with apple bob, { bob }.
A bag with both apples, { ivan, bob }. Hold onto your hats, this is called a universe because at the moment there's nothing in our world except these two apples.
An empty bag aka empty set, {}. This one gets a special symbol, ∅

Sets are often drawn as "venn diagrams", with each set represented as a circle:

Apart from listing all the items, we can also build sets by condition. I can say "R is a set of red apples" to mean { ivan }, considernig ivan is red and bob is green. So far, so good.

Set A is a subset of set B if every element from A is also in B. In our apple world, { ivan } is a subset of { ivan, bob }, but { bob } is not a subset of { ivan }. Obviously, any set is a subset of itself, and {} is a subset of any other set S, because not a single item from {} is missing from S.

There are a few useful operators defined on sets:

Union C = A ∪ B contains all the elements that are in A or in B. Note that A ∪ ∅ = A
Intersection C = A ∩ B contains all the elements that are in A and B. Note that A ∪ ∅ = ∅
Difference C = A \ B contains all the elements that are in A, but not in B. Note that A \ ∅ = A

This should be enough! Let's see how it all maps to types.

What does it have to do with types

So, the big reveal: you can think of "types" as sets of JavaScript values. Then:

Our universe is all the values a JS program can produce.
A type (not even a typescript type, just a type in general) is some set of JS values.
Some types can be represented in TS, while other can not — for example, "non-zero numbers".
A extends B as seen in conditional types and generic constraints can be read as "A is subset of B".
Type union, |, and intersection, &, operators are just the union and intersection of two sets.
Exclude<A, B> is as close as TS gets to a difference operator, except it only works when both A and B are union types.
never is an empty set. Proof: A & never = never and A | never = A for any type A, and Exclude<0, 0> = never.

This change of view already yields some useful insights:

Subtype of type A is a subset of type A. Supertype is a superset. Easy.
Widening makes a type-set wider by allowing some extra values. Narrowing removes certain values. Makes geometrical sense.

I know this all sounds like a lot, so let's proceed by example, starting with a simple case of boolean values.

Boolean types

For now, pretend JS only has boolean values. There are exaclty two — true and false. Recalling the apples, we can make a total of 4 types:

Literal types true and false, each made up of a single value;
boolean, which is any boolean value;
The empty set, never.

The diagram of the "boolean types" is basically the one that we had for apples, just the names swapped:

Let's try moving between type world and set world:

boolean can be written as true | false (in fact, that's exactly how TS impements it).
true is a subset (aka sub-type) of boolean
never is an empty set, so never is a sub-set/type of true, false, and boolean
& is an intersection, so false & true = never, and boolean & true = (true | false) & true = true (the universe, boolean, doesn't affect intersections), and true & never = never, etc.
| is a union, so true | never = true, and boolean | true = boolean (the universe, boolean, "swallows" other intersection items because they're all subsets of universe).
Exclude correctly computes set difference: Exclude<boolean, true> -> false

Now, a little self-assessment of the tricky extends cases:

type A = boolean extends never ? 1 : 0;
type B = true extends boolean ? 1 : 0;
type C = never extends false ? 1 : 0;
type D = never extends never ? 1 : 0;

If you recall that "extends" can be read as "is subset of", the answer should be clear — A0,B1,C1,C1. We're making progress!

null and undefined are just like boolean, except they only contain one value each. never extends null still holds, null & boolean is never since no JS value can simultaneously be of 2 different JS types, and so on. Let's add these to our "trivial types map":

Strings and other primitives

With the simple ones out of the way, let's move on to string types. At first, it seems that nothing's changed — string is a type for "all JS strings", and every string has a corresponding literal type: const str: 'hi' = 'hi'; However, there's one key difference — there are infinitely many possible string values.

It might be a lie, because you can only represent so many strings in finite computer memory, but a) it's enough strings to make enumerating them all unpractical, and b) type systems can operate on pure abstrations without worrying about dirty real-life limitations.

Just like sets, string types can be constructed in a few different ways:

| union lets you constuct any finite string set — e.g. type Country = 'de' | 'us';. This won't work for infinite sets — say, all strings with length > 2 — since you can't write an infinite list of value.
Funky template literal types let you construct some infinite sets — e.g. type V =v${string}; is a set of all strings that start with v.

We can go a bit further by making unions and intersections of literal and template types. Fun time: when combining a union with a template, TS is smart enough to just filter the literals againts the template, so that 'a' | 'b' &a${string}= 'a'. Yet, TS is not smart enough to merge templates, so you get really fancy ways of saying never, such as a${string}` & `b${string} (obviously, a string can't start with "a" and "b" at the same time).

However, some string types are not representable in TS at all. Try "every string except 'a'". You could Exclude<string, 'a'>, but since TS doesn't actually model string as union of all possible string literals, this in fact evaluates back to string. The template grammar can not express this negative condition either. Bad luck!

The types for numbers, symbols and bigints work the same way, except they don't even get a "template" type, and are limited to finite sets. It's a pity, as I could really use some number subtypes — integer, number between 0 and 1, or positive number. Anyways, all together:

Phew, we've covered all primitive, non-intersecting JS / TS types. We've gotten comfortable moving between sets and types, and discovered that some types can't be defined in TS. Here comes the tricky part.

Interfaces & object types

If you think const x: {} = 9; makes no sense, this section is for you. As it appears, our mental model of what TS object types / records / interfaces was built on the wrong assumptions.

First, you'd probably expect types like type Sum9 = { sum: 9 } to act like "literal types" for objects — matching a single object value { sum: 9 }, adjusted for referential equality. This is absolutely not how it works. Instead, Sum9 is a "thing on which you can access propery sum to get 9" — more like a condition / constraint. This lets us call (data: Sum9) => number with an object obj = { sum: 9, date: '2022-09-13' } without TS complaining about unknown date property. See, handy!

Then, {} type is not an "empty object" type corresponding to a {} JS literal, but a "thing where I can access properties, but I don't care about any particular properties". Aha, now we can see what's going on in our initial mind-bender: if x = 9, you can safely x['whatever'], so it satisfies the unconstrained {} interface. In fact, we can even make bolder claims like const x: { toString(): string } = 9;, since we can x.toString() and actuallty get a string. More yet, keyof number gives us "toString" | "toFixed" | "toExponential" | "toPrecision" | "valueOf" | "toLocaleString", meaning that TS secretly sees our primitive type as an object, which it is (thanks to autoboxing). null and undefined do not satisfy {}, because they throw if you try to read a property. Not super intuitive, but makes sense now.

Coming back to my little "| or &" problem, & and | operate on "value sets", not on "object shapes", so you need { name: string } & { age: number } to get objects with both name and (extra hint: and = &) age.

Oh, and what about that odd object type? Since every property on an interface just adds a constraint to the "thing" we're typing, there's no way to declare an interface that filters out primitive values. It's why TS has a built-in object type that means specifically "JS object, not a primitive". Yes, you can intersect with object to get only non-primitive values satisfying an interface: const x: object & { toString(): string } = 9 fails.

Let's add all of these to our type map:

extends

extends keyword in TS can be confusing. It comes from the object-oriented world where you extend a class in the sense of adding functionality to it, but, since TS uses structural typing, extends as used in type Extends<A, B> = A extends B ? true : false is not the same extends from class X extends Y {}.

Instead, A extends B can be read as A is a sub-type of B or, in set terms, A is a subset of B. If B is a union, every member of A must also be in B. If B is a "constrained" interface, A must not violate any of B's constraints. Good news: a usual OOP class A extends B {} fits A extends B ? 1 : 0. So does 'a' extends string, meaning that (excuse the pun) TS extends extends extends.

This "subset" view is the best way to never mix up the order of extends operands:

0 | 1 extends 0 is false, since a 2-element set {0, 1} is not a subset of the 1-element {0} (even though {0,1} does extend {1} in a geometrical sense).
never extends T is always true, because never, the empty set, is a subset of any set.
T extends never is only true if T is never, because an empty set has no subsets except itself.
T extends string allows T to be a string, a literal, or a literal union, or a template, because all of these are subsets of string.
T extends string ? string extends T makes sure that T is exactly string, because that's the only way it can be both a subset and a superset of string.

unknown and any

Typescript has two types that can represent an arbitrary JS value — unknown and any. The normal one is unknown — the universe of JS values:

// It's a 1
type Y = string | number | boolean | object | bigint | symbol | null | undefined extends unknown ? 1 : 0;
// a shorter one, given the {} oddity
type Y2 = {} | null | undefined extends unknown ? 1 : 0;
// For other types, this is 0:
type N = unknown extends string ? 1 : 0;

On a puzzling side, though:

unknown is not a union of all other base types, so you can't Exclude<unknown, string>
unknown extends string | number | boolean | object | bigint | symbol | null | undefined is false, meaning that some TS types are not listed. I suspect enums.

All in all, it's safe to think of unknown as "the set of all possible JS values".

any is the weird one:

any extends string ? 1 : 0 evaluates to 0 | 1 which is basically a "dunno".
Even any extends never ? 1 : 0 evaluates to 0 | 1, meaning that any might be empty.

We should conclude that any is "some set, but we're not sure which one" — like a type NaN. However, upon further inspection, string extends any, unknown extends any and even any extends any are all true, none of which holds for "some set". So, any is a paradox — every set is a subset of any, but any might be empty. The only good news I have is that any extends unknown, so unknown is still the universe, and any does not allow "alien" values.

So, to finish mapping our types, we wrap our entire diagram into unknown bubble:

Today, we've learnt to that TS types are basically sets of JS values. Here's a little dictionary to go from type-world to set-world, and back:

Our universe = all JS values = the type unknown
never is an empty set.
Subtype = narrowed type = subset, supertype = widened type = superset.
A extends B can be read as "A is subset of B".
Union and intersection types are, really, just set union and intersection.
Exclude is an approximation of set difference that only works on union types.

Going back my our initial questions:

0 | 1 extends 0 is false because {0,1} is not a subset of {0}
& and | work on sets, not on object shapes. A & B is a set of things that satisfy both A and B.
unknown is the set of all JS values. any is a paradoxical set that includes everything, but might also be empty.
Intersecting with never gives you never because it's an empty set. never has no effect in a union.
const x: {} = true; works because TS interfaces work by constraining the property values, and we haven't constrained anything here, so true fits.

We still have a lot of TS mysteries to solve, so stay tuned!

Seven habits of bad interviewers

Vladimir Klepov — Mon, 28 Mar 2022 12:11:56 +0000

I’ve been to plenty of bad interviews. Sometimes, only some questions are bad, but usually it goes further than that. Bizarre questions like “what’s the difference between a number and an array” are just a symptom of deeper issues.

Let’s take a step back — why are we interviewing? To hire someone — in our case, a software developer — good at building working software (or at least, ahem, with a good outlook), in our team. A good interview process is precise (not hire people who can’t build software, and not reject people who can), and fast (to save our team’s time, and hire the candidate before anyone else does). That’s it, really. Hire good candidates with a reasonable precision / time ratio.

If this sounds trivial, then why do some interviewers…

Enjoy making the candidate look stupid?
Ask questions that every sane person googles in real-life?
Not help a struggling candidate as they would a struggling teammate?
Ask random questions off the top of their head instead of planning ahead?
Or, conversely, stick to a hard plan even as it stops making any sense?
Spend time asking things that are on your CV?
Have four interviews where one would suffice?
Get into large groups, interrupting each other?

Because they’re bad at interviewing, that’s why. Or, being more positive — because they’ve lost sight of the goal to be achieved behind the ritual. In this article, I go over the major sources of my frustration with interviews, and share some advice for improving your interviews.

Me smart — you stupid

You can’t do much worse when interviewing than adopt “me smart — you stupid” mentality. Let’s face it, feeling smart is nice. The interviewer has all the answers, while the candidate doesn’t. It’s tempting to act like a genius from another planet who knows everything and be like “oh come on think again” and “even my grandmother can do it”. Bad.

This approach obviously misses the whole point of interviewing — we’re trying to hire someone, not humiliate as many people as possible. As such, it’s more evident in larger companies, where the interviewer is often not the person looking to strengthen his team, but some random fellow whose primary objective is to have lunch ASAP.

I also call these interviews exam-like. To pass, you need to give a correct answer to each question on a list. Not a good model for an exam either, but it’s what many of us grew up with. Anyways, an interview is certainly not an exam. The examiner is much more knowledgeable than the student, which is often not true for interviews (especially not middle / senior-level ones). Most exams cover specific known topics, while strict developer curricula don’t exist. Finally, while both exams and interviews can be a selection mechanism, exams have an extra goal of giving the student an objective overview of his abilities. You see, different things.

So, never assume you’re smarter or somehow better than the candidate. But this is just the first step away from exam-like interviews — two other, less evident treats are focusing on the answer and not giving any hints.

Focus on the answer

A common feature of exam-like interviews is the checklist approach. The interviewer asks the question, the candidate answers, we up the score if the answer fits, and move on. The questions therefore tend to be very closed, to facilitate checking correctness, and the difficulty level is tuned by choosing more esoteric topics: a junior JS developer tells about let vs const, the senior — about the event loop.

Real software development is rarely about quickly answering very specific questions. In fact, “how to check browser support for server-sent events” is the most minute detail usually fixed by googling at the final stage of problem-solving. What is it about, then? Many things:

Brainstorming possible approaches
Decomposing a task into bite-sized subtasks
Iterating on the idea to find weak points
Collaborating with teammates

And I haven’t even touched the actual coding yet. Not saying code interviews are worthless, but you get more bang for your buck and test several skills at once by focusing on the problem-solving rather than the right answer.

Problem-solving naturally favors more open-ended questions like “design a slider gallery”, over “what touch events exist”, because they have more process, and thus avoid most of the pitfalls I described in my earlier article on bad interview questions.

Caveat: answer-centric questions work well for screenings. A non-technical recruiter can ask a few sane questions like “What are some React hooks?” and I’m like “useRef useMemo useEffect”, and we know I’m legit. The lack of trust is slightly annoying, but I’ve seen many candidates who can’t tell an iterator from a cucumber, so I feel you.

Not giving any hints

The final treat of “exam-like” interviews that can persist in realistic coding tasks is leaving the candidate alone with the problem, not helping where it’s due. The thinking is that a senior-level developer must know this, and if I don’t — I’m obviously not one. Again, that’s not how development works.

Do you immediately fire or report your teammate who misses a corner case, has room for improvement, or is completely lost? Hopefully not. Collaboration is a key development skill, and you help your friend out, right? Why, then, should the interview be the other way around? Sure,it’s best to plan for edge cases in advance, still cool to identify them yourself and iterate, but it’s not too bad if you can admit and fix a mistake pinpointed to you.

Worst case — don’t even show you’re not satisfied with the answer at all. “So, this is your final answer? Let’s move on then” (to yourself: “Stupid stupid Vladimir, I’ll never hire you”). Happened to me — I solved a particular algorithm problem in linear memory three times in three separate interviews until one interviewer told me that an constant-memory solution actually exists. Until then, I believed the first two rejected me just because they disliked my attitude.

There’s no shame in helping a struggling candidate!

Poor planning

Many interviewers drop in from their daily job with a “fuck, I’m interviewing in 3 minutes!”, don’t have a question list ready because “I’m a senior engineer, I’ll know my senior buddy from a mile”, and proceed with some trivia from a random “best question list” found online (during the interview, of course) or the last tricky thing they’ve done in their job — both poor choices. I know this because I’ve done it myself, and I’m sorry. Planning is king.

Let’s handle the questions first. Ideally, you want to cover several topics related to the role. In a front-end interview these are probably JS/TS, CSS, and some React (or whatever you use) / algo / deployment / performance. Nice way to go through a topic: a few closed question -> open question -> full-on software design task. There are many interdependencies and constraints, so trying to come up with questions on the fly is guaranteed to fail unless you interview daily.

Timing is not as important as you think. Finishing early is fine — whether the candidate aces all the questions in 10 minutes, or fails even the most basic ones, once you got what you came for, filler talk is not the best use for leftover time. Running badly over-time is worse, because something might be scheduled right after the interview, but easily fixed by announcing the duration with a 30-minute extra, e.g. plan for 1.5 hours for a 1-hour interview.

While we’re at it, locking yourself into a very strict script is no better than having no plan at all. If the question sparks some interesting discussion, don’t kill it just to ask more low-level stuff. If you were looking for a senior developer, but happen to have a good junior before you, you’d better adapt — a good junior is still useful and hard to come by. If the candidate has never worked on performance optimization, there’s no use asking in-depth about TTI measurement. Open-ended tasks give you more flexibility in all these cases than “senior-only” questions.

So, do prepare the list of questions that reasonably cover the topics you care about, but don’t obsess over that plan too much — at the end of the day, you’re after a candidate to reinforce your team, not a walking encyclopedia of development.

Ignoring the CV

Interviews are precious face time with the candidate best used to get to know each other, judge social and problem-solving skills. Why waste this opportunity on reiterating things that are evident from the CV?

I worked on large-scale products in big tech companies, got a degree from a top university, and even have a blog and some open-source work — it’s all on my CV, and learning it takes 15 mins before the interview. Not bragging, but it shows I’m probably not too bad. Now, you have a right to be suspicious — maybe I’m a con artist who just made up my CV and forked some repos. A few low-level questions like “sum numbers in an array” are fine. But why spend an hour on “now, write a FUNCTION” and “have you ever worked in a team”? You haven’t taken a single look at the data you had on me, have you, lazy bastard?

Overstretching

Big tech companies are famous for lengthy interview processes: Google has about 8 interviews, and other tech giants are not far behind. So, as a 3-person startup that wants to be the next Google, you need to have many interviews, right? Not so fast. Large companies have many factors that let them get away with (and even require) lengthy interview processes:

The candidates are motivated to work in this particular company and are less likely to accept faster offers while interviewing with you.
A steady stream of candidates justifies high rejection rates and requires ranking precision only achieved by collecting more data.
Many employees available for interviewing. It’s fine to spend 80 hours on 10 candidates when it’s 0.02% of your team’s time, not so much when it’s 67%.
Many teams are hiring at any time, and they reasonably want to have some personal time with the candidates.

I’m fine with 2 interviews and a phone screening, as long as I genuinely like your place, and you can schedule them within a week or two. I’m a lot less enthusiastic about spending 4 hours with a very talkative team lead in your average outsource agency when I can get a comparable offer in a day. Requiring a larger time commitment shows how amazing you think you are. You’d better really excite the candidate more than the companies with shorter hiring processes do.

Having too many interviews is not the only way to overstretch the process. You can only have two, scheduled too far from each other, or be generally slow to organize them and gather feedback. I’m no expert on office administration, but remember that your goal is to hire people before they accept another offer, so please do your best here.

So, only add more interviews if you really need them, and your offering justifies the extra time required. Also remember that extra interviews are not free for your team.

Poor group dynamics

Luckily, 1-on-1 interviews are the standard. However, there are good reasons to have more interviewers: you get a second opinion (as we say in Russia, “one head is good, but two are better”), and several teams that are hiring get to see the candidate in action. However, I often see problems with group dynamics.

Several interviewers, competing and interrupting each other, is just a mess. This might work if you’re making a normal (as possible under the circumstances) conversation without the whole question-answer thing, but these informal interviews have their drawbacks — prioritizing social skills and making it hard to compare many candidates. In a traditional QnA format, it’s better to have one interviewer in charge at any time, with others observing. You can switch roles by section or by answer if you like. But still, there are dangerous spots.

One pitfall is follow-up questions. Every interviewer wants to ask one, then it gets out of control and the follow-ups add no value beyond showing the second interviewer’s here. Once I’ve interviewed with 8 (yes, eight) people at once, and once they were done with their follow-ups to the first question, the time was up and nobody seemed really happy. You often get some back-end dude hiding in the dark to assault you with “OK you can paint your buttons, but can you make me a fault-tolerant DB persistence layer” — wut? Make sure every follow-up helps you assess the candidate better, and isn’t just something that sprung to your mind (see section on not planning ahead).

Another problem that arises with a “passive” interviewer is boredom. Listening to the same answers for the tenth time is not always exciting. However, it’s not very reassuring to see a visibly bored interviewer, especially one who starts playing with the phone because business. The worst of I’ve seen a bored interviewer do is reach into his pants, take something out and chew on it. Hope it was a candy. I needed time to accept this experience.

If you bring buddies to the interview, make sure to agree on who asks what in advance, avoid useless follow-ups that assert your smartness, and make sure not to fall asleep when it’s not your talking time.

Many things can make interviews a horrible experience. Here are some tips to be a better interviewer:

Focus on finding out what the candidate is good at, not on showing off how smart you are. Yes, even if you’re not hiring for yourself.
Seeing how the candidate approaches problems, is better than getting some particular answer you expect. Open questions suit this style better.
If the candidate struggles, help out! People will get stuck in real life, and acting on feedback is a useful skill.
Prepare a question plan that reasonably covers the topics you care about — it’s hard to come up with questions as you go.
But also make sure the plan is flexible enough to allow for unexpected turns. Is hiring a senior engineer experienced in performance optimization really the only good outcome? Don’t you think people are capable of, uhm, learning?
Get as much data on the candidate as possible beforehand — CV, open source work, shared acquaintances and previous interview results are your friends. Asking this again and again is a waste of precious face time.
Don’t make the interview process longer than it needs to be with more interviews or poor scheduling. If you add an interview, you’d better be sure the candidate will want to invest the time in it.
If you have several interviewers, agree on who asks what, make sure the follow-up questions add value beyond showing you’re here, and try not to fall asleep when not talking. Alternatively, try a “conversation-based” interview if it works for you.

Above all, keep you end goal in mind — to hire someone who’ll help you build your product. Happy interviewing!

5 coding interview questions I hate

Vladimir Klepov — Mon, 21 Mar 2022 16:26:29 +0000

I’ve taken part in well over a hundred tech interviews now, on both sides. Some were fun, and some were pure cringe. I’ve been asked if I have kids (supposedly, people with children won’t have time to job hop), and if “I bet my ass I cost that much”. Fun times.

But today I’d like to talk about cringe tech interview question posing as valid ones. They’re on topic, but they do nothing but annoy and frustrate the candidate. Some are beyond saving, while some are fine, but often mishandled by the interviewer. Here are the main offenders:

What happens if you build a circular prototype chain? And other intervew trivia.
How to migrate from webpack 3 to webpack 5? And other specifics.
What’s the difference between a number and an array? And other questions obfuscated with fuzzy wording.
What’s the fastest way to convert a string to number? And other unspecified behavior.
How to make this code sample better? And other questions with missing context.

I’ll share tips both for the interviewers to spend their time better, and for the candidates who hit some of these. Let’s go!

Trivia

This first category comprises questions that are popular in interviews, but rarely arise in practice. What happens when we run the following code?

const x = {};
const y = {};
x. __proto__ = y;
y. __proto__ = x;
console.log(x.field);

We modify the prototype chain in runtime to make it circular. You’ve probably guessed the answer is “nothing good”. You’d never write code like this in production. What a maniac would use the ad-hoc standardized and since deprecated __proto__ property?) Of course, the “correct” answer is that y. __proto__ = x throws TypeError: Cyclic __proto__ value, thanks, that’s good to know.

These questions only show how many interviews the candidate has been in, and it’s in case you’ve picked a popular question. If you’ve just come up with a “tricky question that’s not on the web” yourself, it’s just a dice roll of spec memorization.

Old-style JS questions are a notable sub-category of trivia. Yes, those of us who started programming back before 2015 know how var hoisting works, and how to declare (and even extend) a class with .prototype Here, you’re effectively testing when the developer started learning JS (or if he’s worked on a legacy codebase), which is already on the CV. Maybe worth it if you have a legacy project yourself.

As an interviewer, avoid questions that have nothing to do with the real-life development. The biggest fans of these questions are non-technical people (CEOs, founders, PMs) trying to conduct coding interviews by going over a question list found online. Bad news — it doesn’t work like that. Either hire / borrow a real developer just for the interviews, or stick to soft-skill topics and experience anecdotes.

The only way to answer these is, sadly, to participate in many interviews — or, as a cheap substitute, to browse lists of “TOP JS questions ever, guaranteed”. No one can realistically know every corner case of the language and the libraries.

Specifics

What issues does migrating to webpack 6 have? How do you check browser support for server-sent events? What aria-role should a modal page have? I don’t know. I usually google for this kind of things, and I’m pretty good at it.

This is what happens when you take my advice on using real-life programming questions a bit too seriously, and drop random problems you recently solved into an interview. Obviously, you’ve made your research, figured out the answer, and are pleased with yourself. But I’m not you, we have different experience to complement each other — and isn’t that even better? Don’t label me as an idiot just because I’ve never touched a certain area of web development.

Instead, ask the candidate about a challenging problem she recently solved — it’s going to be far more entertaining and valuable for both of you.

If you’re asked this question, and have never faced the problem yourself, you’re in trouble. Try to access all the background knowledge around the topic you might have, and maybe you can even figure this out based on common sense.

Obfuscated questions

“What’s the difference between a number and an object” is the most surprising question ever — double the surprise every time I hear it yet again. Come on, what’s the difference between your head and a sweet potato fresh out of oven? Excuse me, am I interviewing for a comedian?

The problem here is that a very concrete answer is expected (I figured out it’s “number is immutable”), but asking it directly is “too simple”, so you dress it up by presenting it as open-ended, and add some fuzziness, but in the end it just becomes impossible to decipher what you were trying to ask in the first place.

The worst part is that you can’t even give a hint, because the hint is the answer, so you’re bound to circle around confusing everyone further. “What can you do with numbers that you can’t with objects?” (Add them? Coerce to false?). “Think again, do numbers have properties?” (in a way, they do). What a waste of time!

Again, interview experience is key here. Once you wrap your head around the common JS interview questions and topics, you’ll get better at recognizing them whatever costume they’re dressed in.

As an interviewer, prefer direct questions (“Which JS types are immutable?”) or at least make sure your wording points in the intended direction, not all over the place (“What’s the difference between primitive types and objects?”).

Unspecified behavior

Will console.log(Object.keys({ x: 0, y: 0 }).join()) log x,y or y,x? Is x[key] faster than x.find(e => e.key === key)? Under normal circumstances I know the answers are x,y (addition order) and yes, but it’s not on the spec, so I wouldn’t over-rely on it.

Performance-related questions are the most popular of this bunch. JS runtimes change fast, and even if you’ve seen some code perform better a few years ago, it might not be the case any more. The fact that built-in data structures in JS do not specify operation complexity does not help either. We reasonably assume object access obj[key] to take O(1), but in reality this depends on many factors — object size, insert / remove frequency, whether the keys are string literals (see benchmark). And even when the difference does exist, it’s usually abysmal and irrelevant to actual front-end development.

Overall, these questions are good for assessing both the practical knowledge of the common-case performance, the difference between runtimes, and how it applies to everyday development. As an interviewer, you only need two things to handle this well: be aware of the implementation-dependence yourself and have an open mind when it comes to unexpected answers. These questions are certainly not suitable for a non-interactive interview, such as a single-choice online survey (Pick the fastest method: a) a.pop() b) a.shift() c) a.length -= 1), because there’s no one right answer here.

Missing-context questions

Open-ended questions are among the best you can ask in an interview — they’re challenging, and reveal both the candidate’s problem-solving skills and real-world experience. However, these questions are unforgiving to lazy interviewers — both sides should put in some effort to make them work. The two prime ways to mess these up are being uncollaborative and locking in to one possible solution.

For example, what’s wrong with this function?

function map(arr, fn) { 
  for (var i = 0; i < arr.length; i++) { 
    arr[i] = fn(arr[i]); 
  }
  return arr;
}

Why, looks perfectly fine to me. Or maybe not. Depends on what you’re trying to achieve. The code is rarely “right” or “wrong” by itself. Yes, mutating arr is non-idiomatic lately, but maybe it works in-place as an optimization. Yes, the use of var is frowned upon, but maybe it’s a library that’s supposed to work in IE6. Yes, we could replace the for (;;) with a .map or a for..of, but then we’d lose support for all array-likes. See, it all depends on the context. I can endlessly produce variations of this code, but I’d rather not if it’s not causing any trouble.

This question is often presented as “refactor this code to make it BETTER” — sure to excite any junior developer. Good thing grumpy old Vladimir is here to tell you that “refactoring” with no clear goal is the greatest waste of time out there.

To illustrate the solution lock-in problem, suppose you give me a slider gallery implemented with a horrendous mess of jQuery and ask to improve it. Problem is, you believe the best way to spend an hour on this is to write unit tests and convert to React. I think I should change jQuery to vanilla DOM and improve UX with better overscroll handling. Neither of us is right or wrong. In real life, the project goals and technical direction sets the context — how many jQuery dependencies we have across the codebase, if we intend on migrating to React, manual QA availability.

When asking an open-ended question, either let go of your expected answer and focus on the problem-solving process, or introduce the missing requirements to guide towards your desired solution.

So, here are the five types of interview questions that I hate, most hopeless to nice-but-dangerous:

Trivia: questions that often arise in interview, but never in real life, e.g. “what happens if you create a circular prototype chain”. These test for interview experience, not development skills. Avoid.
Specifics: solutions to unique real-life problems. Example: “how to migrate webpack 3 to webpack 5”. Might work if the answer can be from the expected background knowledge or if the area is super critical to your product. Instead, ask about a challenging problem the candidate recently solved.
Obfuscated questions: simple questions made harder by fuzzy wording, such as “what’s the difference between a number and an object?” instead of “are JS numbers mutable?”. Avoid.
Implementation questions: the answer depends on a specific JS runtime, e.g. “what’s the fastest way to loop over a list”. Avoid strong wordings and don’t bikeshed if the answer is not what you expected.
Missing context: answer requires additional details, e.g. “how to improve this code”. Amazing question as long as you’re ready to problem-solve together, provide the missing constraints and give credit for noting the distinct possibilities. Worst question if you expect a specific question while many objectively good alternatives exist.

Here’s my advice on improving interview questions, as a nice flowchart:

For candidates, I’m afraid, I have fewer actionable tips. Sure, practice makes perfect, and skimming the common interview questions won’t hurt even if you’re a hot shot lead senior, but other than that it’s hard to escape a bad question with an bad interviewer. You can’t convince the interviewer to change the question or his approach on the fly (if you can, apply for a top-tier sales representative position instead). Tough luck, but be ready to admit you don’t know some things, and try to work from the knowledge you have around the topic.

Good luck with your interviews, and see you later!

Using global memoization in React

Vladimir Klepov — Wed, 16 Feb 2022 08:28:06 +0000

When our React apps get slow, we usually turn to useMemo to avoid useless job on re-render. It’s a hammer that often works well, and makes it hard to shoot yourself in the foot. But useMemo is not a silver bullet — sometimes it just introduces more useless work instead of making your app faster.

In this article, I explore the less conventional caching techniques in React that can do wonders to optimize your apps:

First, we must understand exactly how useMemo works — and why.
What are some use cases where useMemo does not help much?
Then, we examine four global caching methods, where cache is shared between components. As usual, they come with different tradeoffs, and some are even dangerous if used carelessly.

There’s a neat cheat sheet awaiting you at the end. Let’s dive in!

Inside useMemo

To see if useMemo fits our particular use case, we must know how, precisely, it works. To quote the docs, useMemo will only recompute the memoized value when one of the dependencies has changed. This is rather ambiguous, so let’s check against the implementation:

The cache is initialized when mounting a component instance, and destroyed when unmounting.
The cache is never shared between different component instances.
The cache stores just a single value — the last one.

This is a sensible default. Storing one value never leaks memory, even if you use an unstable dependency. Say our memo (and useCallback is just a wrapper over useMemo) depends on an unstable arrow, onClick:

const onClick = (id) => console.log('click', id);
const handleClick = useCallback(() => {
  onClick(props.id);
}, [onClick, props.id]);

Now we create a new handleClick on every render. If useMemo stored all the previous values, every handleClick would occupy memory forever — bad. Also, storing N values requires N dependency comparisons when reading, which is N times slower than checking once. Sure, useMemo is worthless here, but at least it does not explode.

Localizing cache to a single component guards against missing deps. Suppose you’re sure a scope variable never changes during the component lifetime, so you just omit it from the dependency array:

const [clicks, setClicks] = useState(0);
const handleClick = useCallback(() => { 
  setClicks(c => c + 1);
}, []);

If the cache was shared among multiple components, distinct handleClicks would call the same setClicks, so only one counter would increment — unexpected!

Good job, React team — thanks for saving us the trouble of debugging this! But this safe implementation has its limitations.

useMemo pitfalls

While a great default, the locality and single-value limit of useMemo make it useless in some scenarios. For example, consider this attempt at memoizing a large city list:

const RouteItem = () => { 
  const cities = useMemo(() => [{ 
    label: 'Moscow', value: 'MOW' 
  }, { 
    label: 'Saint Petersburg', value: 'LED' 
  }, // 1000 more cities], []); 
  return <select> 
    {cities.map(c => 
      <option value={c.value}>{c.label}</option>
    )} 
  </select>;
};

If we render a 1000 RouteItems, each one gets its own array, which is wasteful. In this case, we’d prefer sharing the cache between different instances.

Another problem point is alternating dependency values. Let’s say we want to generate color scheme based on checkbox value:

const SchemePicker = (props) => { 
  const [isDark, setDark] = useState(false); 
  const colors = useMemo(() => ({ 
    background: isDark ? 'black' : 'white', 
    color: isDark ? 'white' : 'black', 
  }), [isDark]); 
  return <div style={colors} {...props}> 
    <button onChange={() => setDark(!isDark)}> 
      toggle theme 
    </button> 
    {props.children} 
  </div>;
};

Here, we only have two possible dependency values, true and false, so there is no risk of a memory leak. Yet, on every checkbox change, we compute a fresh color scheme. The old one would be just fine, thank you.

So, in some cases we’d like to:

Share cache between different component instances.
Remember several values, not just the last one.

No problem, with the power of JS at our disposal we can make it happen.

Global memo

If we want to reuse a value between component instances, no hook can save us, because both useState and useRef are local to component instance. But we can extract the cache into module scope, and work from there:

// this is shared between all components
const cache = /* some cache */;
const Component = () => { 
  // cache is always the same object 
  const value = cache.get(deps);
}

Precomputed global constant

The simplest kind of “cache” is one with no dependencies — a constant that’s usable in every component. And the simplest solution is to just to declare this constant right away:

const cities = [
  { label: 'Moscow', value: 'MOW' }, 
  { label: 'Saint Petersburg', value: 'LED' }, 
  // 1000 more cities
];
// yay, every RouteItem refers to the same cities
const RouteItem = () => { 
  return <select> 
    {cities.map(c => 
      <option value={c.value}>{c.label}</option>
    )} 
  </select>;
};

Having just one value for all components seems limiting. But, if we know all the possible dependency values in advance, we can just precompute the value for each dependency:

const schemes = { 
  dark: { background: 'black', color: 'white' }, 
  light: { background: 'white', color: 'black' },
};
const SchemePicker = (props) => { 
  const [isDark, setDark] = useState(false); 
  // we only have 2 values, each one is stable 
  const colors = schemes[isDark ? 'dark' : 'light']; 
  return <div style={colors} {...props}> 
    <button onChange={() => setDark(!isDark)}> 
      toggle theme 
    </button> 
    {props.children} 
  </div>;
};

However, this technique comes with some drawbacks. Building the object in the initial execution phase delays the first paint, even if you don’t need the value right away. All the data needed to construct the value must be available when the script is initially executed. If any of this is a concern, let’s move on to the next technique!

Lazy global constant

So, we want to share a single value between all components, but we want to compute it only when we need it. Fine, it’s a well-known pattern:

let citiesCache;
// getCities intercepts accessing cities
const getCities = () => { 
  // use cached value if it exists 
  if (citiesCache) { 
    return citiesCache; 
  } 
  // otherwise put the array into the cache 
  citiesCache = [
    { label: 'Moscow', value: 'MOW' }, 
    { label: 'Saint Petersburg', value: 'LED' }, 
    // 1000 more cities
  ]; 
  return citiesCache;
};
const RouteItem = () => { 
  return <select> 
    {getCities().map(c => 
      <option value={c.value}>{c.label}</option>
    )}
  </select>;
};

Here, we delay building the value until we actually need it. Great! And we could even pass some data from an API to the builder, as long as it never changes. Fun fact: storing data in a state manager or an API cache is actually an example of this technique.

But what if we try to generalize this method for multiple values, just like we did with a precomputed map? Oh, that’s a whole different story!

True memo

Let’s up our game by letting every component get a special version of city list, with one city excluded. We’d still like to share the cache between several instances, just in case. It’s not that hard:

const cities = [
  { label: 'Moscow', value: 'MOW' }, 
  { label: 'Saint Petersburg', value: 'LED' }, 
  // 1000 more cities
];
const filterCache = {};
const getCitiesExcept = (exclude) => { 
  // use cached value if it exists 
  if (filterCache[exclude]) { 
    return filterCache[exclude]; 
  } 
  // otherwise put the filtered array into the cache
  filterCache[exclude] = cities
    .filter(c => c.value !== exclude); 
  return filterCache[exclude];
};
const RouteItem = ({ value }) => { 
  return <select> 
    {getCitiesExcept(value) 
      .map(c => <option value={c.value}>{c.label}</option>)}
  </select>;
};

This works, but global caches are vulnerable to infinite growth problem. In a long-lived app, you might eventually get to the point where every possible city was excluded, leaving you with a 1000 copies of your 1000-item array in the cache, most of them useless. To protect against this, we need some way to limit the cache size.

LRU cache

To restrict cache size, we need some way to choose exactly which elements to “forget”. This is called cache replacement policy, and there are surprisingly many approaches.

We’ll stick to the simplest method — least-recently used, or LRU cache. We only remember N last values. For example, after passing numbers 1, 2, 3, 1 to an LRU cache of size 2, we only store the values for 3 and 1, while the value for 2 was thrown away. The implementation is not interesting, hope you believe this is doable (see flru for details). It’s worth noting that the original useMemo is actually an LRU cache of size 1, because it only stores one last value.

While it sounds good on paper, global bounded cache does not actually work that well for our use cases. To see why, let’s consider a cache of size 1. If we have several component instances alive at once, they likely have different dependency values. If they render in alternating order, every instance encounters the value from the previously rendered one, which is a cache miss, and has to recompute. So, we end up recomputing on every render, and doing some useless comparisons.

More generally, a cache of size N is likely to have misses once N+1 components with different values are alive, and become useless at 2N components. This is not a good quality — a cache shouldn’t care how many consumers exist. We could experiment with other replacement policies — say, frequency-based caches — but they’re way harder to implement, and I feel like React apps don’t have cache usage patterns that could benefit from them.

There is, however, one case where it works: if you have N possible dependency values, and N is small — say, true / false, or a number 1..10, a cache of size N has you fully covered with 100% cache hits, and only computes values when needed. But if that’s the case, a simple global cache works just the same, without the overhead of tracking usage order.

Recap time! We’ve started out by looking at useMemo in detail. useMemo cache is never shared between component instances, lives as long as the instance lives, and only stores one last value. There are good reasons for these decisions.

However, this makes useMemo not usable in some cases:

When you want to reuse a value between components (e.g. always the same large object)
When your dependency quickly alternates between several values (e.g. true / false / true etc.)

Then, we examined 4 (4-and-a-half? 5?) caching techniques with a globally shared cache that overcome these issues:

Just use a module constant. Simple, reliable, but builds the object during initial script execution — suboptimal if the object is heavy and not needed during initial render.
Precomputed map — a simple extension of module constant that stores several values. Same drawbacks.
Lazy constant — delay building the object until it’s needed, then cache forever. Removes module constant init delay during script init time.
Full memo — saves all the results of function calls with all arguments. Leaks memory when there are many possible dependency values / combinations. Good when there are few possible inputs. Use with care.
Bounded cache (e.g. LRU). Fixes the memory leak problem, but useless when the number of components alive with different deps is larger than cache size. Not recommended.

Here’s a cheat sheet to help you remember these techniques:

These techniques are useful in regular react apps, and can up your performance. But we don’t always need our cache to be shared between component instances. Luckily, all these methods also work when scoped to a component — stay tuned for the next post on alternate useMemo implementations.

Good advice on JSX conditionals

Vladimir Klepov — Mon, 17 Jan 2022 15:58:03 +0000

Conditional rendering is a cornerstone of any templating language. React / JSX bravely chose not to have a dedicated conditional syntax, like ng-if="condition", relying on JS boolean operators instead:

condition && <JSX /> renders <JSX /> iff condition is truthy,
condition ? <JsxTrue /> : <JsxFalse /> renders <JsxTrue /> or <JsxFalse /> depending on the truthiness of condition.

Courageous, but not always as intuitive as you’d expect. Time after time I shoot myself in the foot with JSX conditionals. In this article, I look at the trickier corners of JSX conditionals, and share some tips for staying safe:

Number 0 likes to leak into your markup.
Compound conditions with || can surprise you because precedence
Ternaries don’t scale.
props.children is not something to use as a condition
How to manage update vs remount in conditionals.

If you’re in a hurry, I’ve made a cheat sheet:

Beware of zero

Rendering on numerical condition is a common use case. It’s helpful for rendering a collection only if it’s loaded and non-empty:

{gallery.length && <Gallery slides={gallery}>}

However, if the gallery is empty, we get an annoying 0 in out DOM instead of nothing. That’s because of the way && works: a falsy left-hand side (like 0) is returned immediately. In JS, boolean operators do not cast their result to boolean — and for the better, since you don’t want the right-hand JSX to turn into true. React then proceeds to put that 0 into the DOM — unlike false, it’s a valid react node (again, for good — in you have {count} tickets rendering 0 is perfectly expected).

The fix? I have two. Cast the condition to boolean explicitly in any way you like. Now the expression value is false, not 0, and false is not rendered:

gallery.length > 0 && jsx
// or
!!gallery.length && jsx
// or
Boolean(gallery.length) && jsx

Alternatively, replace && with a ternary to explicitly provide the falsy value — null works like a charm:

{gallery.length ? <Gallery slides={gallery} /> : null}

Mind the precedence

And (&&) has a higher precedence than or (||) — that’s how boolean algebra works. However, this also means that you must be very careful with JSX conditions that contain ||. Watch as I try to render an access error for anonymous or restricted users…

user.anonymous || user.restricted && <div className="error" />

… and I screw up! The code above is actually equivalent to:

user.anonymous || (user.restricted && <div className="error" />)

Which is not what I want. For anonymous users, you get true || ...whatever..., which is true, because JS knows the or-expression is true just by looking at the left-hand side and skips (short-circuits) the rest. React doesn’t render true, and even if it did, true is not the error message you expect.

As a rule of thumb, parenthesize the condition as soon as you see the OR:

{(user.anonymous || user.restricted) && <div className="error" />}

For a more sneaky case, consider this ternary-inside-the-condition:

{user.registered ? user.restricted : user.rateLimited && 
  <div className="error" />}

Parentheses still help, but avoiding ternaries in conditions is a better option — they’re very confusing, because you can’t even read the expression out in English (if the user is registered then if the user is restricted otherwise if the user is rate-limited, please make it stop).

Don’t get stuck in ternaries

A ternary is a fine way to switch between two pieces of JSX. Once you go beyond 2 items, the lack of an else if () turns your logic into a bloody mess real quick:

{isEmoji ? 
  <EmojiButton /> : 
  isCoupon ? 
    <CouponButton /> : 
    isLoaded && <ShareButton />}

Any extra conditions inside a ternary branch, be it a nested ternary or a simple &&, are a red flag. Sometimes, a series of && blocks works better, at the expense of duplicating some conditions:

{isEmoji && <EmojiButton />}
{isCoupon && <CouponButton />}
{!isEmoji && !isCoupon && isLoaded && <ShareButton />}

Other times, a good old if / else is the way to go. Sure, you can’t inline these in JSX, but you can always extract a function:

const getButton = () => { 
  if (isEmoji) return <EmojiButton />; 
  if (isCoupon) return <CouponButton />; 
  return isLoaded ? <ShareButton /> : null;
};

Don’t conditional on JSX

In case you’re wondering, react elements passed via props don’t work as a condition. Let me try wrapping the children in a div only if there are children:

const Wrap = (props) => { 
  if (!props.children) return null; 
  return <div>{props.children}</div>
};

I expect Wrap to render null when there is no content wrapped, but React doesn’t work like that:

props.children can be an empty array, e.g. <Wrap>{[].map(e => <div />)}</Wrap>
children.length fails, too: children can also be a single element, not an array (<Wrap><div /></Wrap>).
React.Children.count(props.children) supports both single and multiple children, but thinks that <Wrap>{false && 'hi'}{false && 'there'}</Wrap> contains 2 items, while in reality there are none.
Next try: React.Children.toArray(props.children) removes invalid nodes, such as false. Sadly, you still get true for an empty fragment: <Wrap><></><Wrap>.
For the final nail in this coffin, if we move the conditional rendering inside a component: <Wrap><Div hide /></Wrap> with Div = (p) => p.hide ? null : <div />, we can never know if it’s empty during Wrap render, because react only renders the child Div after the parent, and a stateful child can re-render independently from its parent.

For the only sane way to change anything if the interpolated JSX is empty, see CSS :empty pseudo-class.

Remount or update?

JSX written in separate ternary branches feels like completely independent code. Consider the following:

{hasItem ? <Item id={1} /> : <Item id={2} />}

What happens when hasItem changes? Don’t know about you, but my guess would be that <Item id={1} /> unmounts, then <Item id={2} /> mounts, because I wrote 2 separate JSX tags. React, however, doesn’t know or care what I wrote, all it sees is the Item element in the same position, so it keeps the mounted instance, updating props (see sandbox). The code above is equivalent to <Item id={hasItem ? 1 : 2} />.

When the branches contain different components, as in {hasItem ? <Item1 /> : <Item2 />}, React remounts, because Item1 can’t be updated to become Item2.

The case above just causes some unexpected behavior that’s fine as long as you properly manage updates, and even a bit more optimal than remounting. However, with uncontrolled inputs you’re in for a disaster:

{mode === 'name' 
  ? <input placeholder="name" /> 
  : <input placeholder="phone" />}

Here, if you input something into name input, then switch the mode, your name unexpectedly leaks into the phone input. (again, see sandbox) This can cause even more havoc with complex update mechanics relying on previous state.

One workaround here is using the key prop. Normally, we use it for rendering lists, but it’s actually an element identity hint for React — elements with the same key are the same logical element.

// remounts on change
{mode === 'name' 
  ? <input placeholder="name" key="name" /> 
  : <input placeholder="phone" key="phone" />}

Another option is replacing the ternary with two separate && blocks. When key is absent, React falls back to the index of the item in children array, so putting distinct elements into distinct positions works just as well as an explicit key:

{mode === 'name' && <input placeholder="name" />}
{mode !== 'name' && <input placeholder="phone" />}

Conversely, if you have very different conditional props on the same logical element, you can split the branching into two separate JSX tags for readability with no penalty:

// messy
<Button 
  aria-busy={loading} 
  onClick={loading ? null : submit}
>
  {loading ? <Spinner /> : 'submit'}
</Button>
// maybe try:
loading 
  ? <Button aria-busy><Spinner /></Button> 
  : <Button onClick={submit}>submit</Button>
// or even
{loading && 
  <Button key="submit" aria-busy><Spinner /></Button>}
{!loading && 
  <Button key="submit" onClick={submit}>submit</Button>}
// ^^ bonus: _move_ the element around the markup, no remount

So, here are my top tips for using JSX conditionals like a boss:

{number && <JSX />} renders 0 instead of nothing. Use {number > 0 && <JSX />} instead.
Don’t forget the parentheses around or-conditions: {(cond1 || cond2) && <JSX />}
Ternaries don’t scale beyond 2 branches — try an && block per branch, or extract a function and use if / else.
You can’t tell if props.children (or any interpolated element) actually contains some content — CSS :empty is your best bet.
{condition ? <Tag props1 /> : <Tag props2 />} will not remount Tag — use unique key or separate && branches if you want the remount.

Make useRef lazy — 4 ways

Vladimir Klepov — Tue, 30 Nov 2021 11:52:33 +0000

I love useRef, but it lacks the lazy initializer functionality found in other hooks (useState / useReducer / useMemo). useRef({ x: 0, y: 0 }) creates an object { x: 0, y: 0 } on every render, but only uses it when mounting — it subsequent renders it’s thrown away. With useState, we can replace the initial value with an initializer that’s only called on first render — useState(() => ({ x: 0, y: 0 })) (I’ve explored this and other useState features in my older post). Creating functions is very cheap in modern JS runtimes, so we skip allocating memory and building the object for a slight performance boost.

I’m not super excited about doing useless work, and useRef is your primary tool for avoiding useless re-renders. In this post, I’ll show you four ways to support lazy initializer in useRef:

Move initialization to useEffect
Sync lazy useRef initializer that works like useState initializer.
Lazy useRef on top of useState (almost zero code!)
A useRef that only computes the value when you read .current

Use cases

Any ref that involves an object can benefit from lazy initialization. I use such refs a lot for tracking gestures:

const touch = useRef({ x: 0, y: 0 });
const onTouchMove = e => { 
  touch.current = { 
    x: e.touches[0].clientX, 
    y: e.touches[0].clientY, 
  };
};

A lazy initializer is useless for atomic values like useRef(9), since those are cheap to create, too.

For a slightly different use case, sometimes we want a stateful object (often a Resize/IntersectionObserver) with a stable identity — useMemo does not guarantee it. We don’t really want to reassign current, so a RefObject API is not needed:

// Would be nice
const observer = useStableMemo(() => new IntersectionObserver(cb), []);
// Why write observer.current if you never swap an observer?
const rootRef = useRef(e => observer.observe(e)).current;

For each technique, we’ll see how good it is at supporting both use cases.

The async way

The most intuitive way to lazy-initialize a ref is combining a value-less useRef() with a mount effect:

const ref = useRef();
useEffect(() => {
  ref.current = initialValue;
}, []);

Nicely, init inside an effect does not (normally) block the paint, allowing you to paint a touch faster. However, this implementation is not always convenient, because the .current value is not accessible before the effect — in the first render phase, in DOM refs, useLayoutEffect, and even in some other useEffects (inside child components and ones scheduled before the init effect) — try it yourself in a codepen. If the whole useRef + useEffect construction is written inline in a component, you at least see that the initialization is delayed. Wrapping it into a custom hook increases the chances of a misuse:

const observer = useLazyRef(() => new IntersectionObserver(...));
// spot the bug
useLayoutEffect(() => {
  observer.current.observe(node);
}, []);

The logic relying on .current is awkwardly pushed into effects, complicating your code:

const [width, setWidth] = useState(0);
const node = useRef();
const observer = useLazyRef(() => 
  new ResizeObserver(([e]) => setWidth(e.borderBoxSize.width)));
useEffect(() => {
  observer.current.observe(node.current)
}, []);
return <div ref={node} data-width={width} {...props} />

Replacing useEffect with useLayoutEffect does not help much — a bunch of places that can’t access the current still exists (first render, DOM refs, child useLayoutEffects), and now the initialization blocks the paint. As we’ll see now, better ways to initialize early exist.

The useEffect approach works OK if you only need .current later — in other effects, timeouts or event handlers (and you’re 100% sure those won’t fire during the first paint). It’s my least favorite approach, because the other ones work better and avoid the “pre-initialization gap”.

The DIY way

If we want the .current value to be available at all times, but without re-creation on every render (a lot like useState / useMemo), we can just build a custom hook over bare useRef ourselves (see codepen):

// none is a special value used to detect an uninitialized ref
const none = {};
function useLazyRef(init) {
  // not initialized yet
  const ref = useRef(none);
  // if it's not initialized (1st render)
  if (ref.current === none) {
    // we initialize it
    ref.current = init();
  }
  // new we return the initialized ref
  return ref;
}

This implementation is a good default for custom useLazyRef hooks: it works anywhere — inside render, in effects and layout effects, in listeners, with no chance of misuse, and is similar to the built-in useState and useMemo. To turn it into a readonly ref / stable memo, just return ref.current — it’s already initialized before useLazyRef returns.

Note that using null as the un-initialized value breaks if init() returns null, and setting ref.current = null triggers an accidental re-initialization on next render. Symbol works well and might be more convenient for debugging.

This is the most convenient approach for storing observers, because they’re safe to use from DOM refs:

const [width, setWidth] = useState(0);
const observer = useLazyRef(() => 
  new ResizeObserver(([e]) => setWidth(e.borderBoxSize.width))).current;
const nodeRef = useRef((e) => observer.observe(e)).current;
return <div ref={nodeRef} data-width={width} {...props} />

The only downside is that the initializer runs even if we never read the value. I’ll show you how to avoid this, but first let’s see how we can (and can’t) build this flavor of lazy useRef over other hooks.

The resourceful way

If useState has the lazy initializer feature we want, why not just use it instead of writing custom code (codepen)?

const ref = useState(() => ({ current: init() }))[0];

We useState with a lazy initializer that mimics the shape of a RefObject, and throw away the update handle because we’ll never use it — ref identity must be stable. For readonly ref / stable-memo we can skip the { current } trick and just useState(init)[0]. Storing a mutable object in useState is not the most orthodox thing to do, but it works pretty well here. I imagine that at some point future react might choose to rebuild the current useState by re-initializing and re-applying all the updates (e.g. for HMR), but I haven’t heard of such plans, and this will break a lot of stuff.

As usual, anything doable with useState can also be done with useReducer, but it’s slightly more complicated:

useReducer(
  // any reducer works, it never runs anyways
  v => v, 
  // () => {} and () => 9 work just as well
  () => ({ current: init() }))[0];
// And here's the stable memo:
useReducer(v => v, init)[0];

The most obvious base hook, useMemo, doesn’t work well. useMemo(() => ({ current: init() }), []) currently returns a stable object, but React docs warn against relying on this, since a future React version might re-initialize the value when it feels like it. If you’re OK with that, you didn’t need ref in the first place.

useImperativeHandle is not recommended, too — it has something to do with refs, but its implemented to set the value in a layout effect, similar to the worst one of our async options. Also, it

So, useState allows you to build a lazy ref with almost zero code, at a minor risk of breaking in a future react version. Choosing between this and a DIY lazy ref is up to you, they work the same.

The really lazy way

I’d argue that what we’ve discussed so far isn’t really lazy — sure, you avoid useless job on re-render, but you still eagerly compute the initial value on first render. What if we only computed the value on demand, when someone reads .current?

const none = {};
function useJitRef(init) {
  const value = useRef(none);
  const ref = useLazyRef(() => ({
    get current() {
      if (value.current === none) {
        value.current = init();
      }
      return value.current;
    },
    set current(v) {
      value.current = v;
    }
  }));
  return ref;
}

Tricky! See codepen, and let me break it down for you:

Wrap the bare ref with a get / set interceptor
Reading current goes through the get(), computing the value on first read and returning the cached value later.
Assigning current updates the value instantly and removes the need to initialize.
The wrapper object is a useLazyRef itself to preserve the builtin useRef guarantee of stable identity and avoid extra object creation.

For readonly ref / stable memo, try the simpler getter function approach suggested in react docs:

const none = {};
function useMemoGet(init) {
  const value = useRef(none);
  return useCallback(() => {
    if (value.current === none) {
      value.current = init();
    }
    return value.current;
  }, []);
}

Is it worth the trouble? Maybe, maybe not. The code is more complicated than the eager useLazyRef. If the initializer is really heavy, and you use the value conditionally, and you often end up not needing it, sure, it’s a good fit. Honestly, I have yet to see a use case that fits these conditions.

This is a very interesting and flexible technique that supports many variations:

Pre-compute the value, e.g. in requestIdleCallback(() => ref.current)
Allow for lazy updates — don’t set the explicit value, but provide a new way to compute it: ref.current = () => el.clientWidth
Replace updating with invalidation — say, with getWidth = useMemoGet(() => el.clientWidth) you can mark the cached value as stale with getWidth.invalidate() on content change.

We’ve covered 4 good base techniques (useState is an alternative implementation of ) for creating lazy useRef. They all have different characteristics that make them useful for different problems:

Initialize in useEffect — not recommended because it’s easy to hit un-initialized .current.
Sync custom-built useRef works well, but blocks first render. Good enough for most cases.
Putting the value into useState‘s initializer, but hiding the update handle. Least code, but a chance of breaking in future react versions.
On-demand useRef that only computes the value when you read .current — complicated, but flexible and never computes values you don’t use.

Hope you find this useful! If you want to learn more about react, check out my other posts.

Open source starter pack for JS devs

Vladimir Klepov — Sat, 20 Nov 2021 13:25:25 +0000

So you’ve decided to open-source your project. Amazing! Bad news first: writing code is only the beginning. The information for library authors on the web is surprisingly fragmented, so I’ve decided to put together a list of things to keep in mind when open-sourcing a JS library:

Decent docs, an OSS license, TypeScript definitions and a changelog are a must if you want anyone to use your library.
Build setup of a library is different from that of an app — but even simpler, if you know what to do.
peerDependenies are a thing (also, npm / yarn version resolution is a nightmare).

I’ll give you enough info on each point to get started without going too deep.

I assume you’re comfortable with babel and webpack (or any other build toolchain), and have followed some basic tutorial on publishing an npm package. I also suggest you host your code on GitHub — it has a ton of features useful for OSS, and any other choice is just bizarre in 2021. Let’s pick up where you’ve written some code, pushed it to a public github repo, set up your package.json with name, version and main, and got npm publish to pass. There’s still a bumpy ride ahead.

Documentation

Your library will be used by people who have no idea what it’s supposed to do, and how it works. For a small project, don’t block yourself into building a fancy docs website — a readme.md file in the repo root is enough. Writing the actual docs is a better way to spend your time. Make sure to include:

What problem does your project solve? Does your library do something I need?
How to install it? Even if it’s npm i my-project, don’t make me guess the package name.
A basic usage example. Just something to copy-paste and get started with it.
Full API docs. What can the library do? Does it cover all my use-cases? What arguments do I pass where? I shouldn’t have to read the source to answer these questions.

See markdown cheatsheet if you’re not fluent yet.

License

(I’m not a lawyer, but this is my understanding). A project without an explicit license is closed source by default — the users can look at the code, but can’t legally use it. Choose an open-source license, copy the text into a LICENSE file to your repo, put the name in the license field of package.json, and probably mention it in the readme. MIT license is a good choice if you just want everyone to use your code and don’t have a strong opinion on everything must be open-source.

Package structure

When building an app, you have some transpiler + bundler (probably babel + webpack, but anything goes) setup to turn your source into someting that runs in a browser. If you don’t want to make your users jump around patching webpack config, you need some of that, too. Exactly how you should package your code is a complex topic, but let me scratch the surface for you. TLDR:

If you use extended JS (JSX / TS / whatever), or want to support older runtimes with zero setup, do a babel (or friends) pass.
Have a ES-module build for tree-shaking, and a legacy CommonJS build.
Be clear about supported browsers / node versions. Too much = bloat, too little = broken apps for users who don’t do extra setup (they won’t).
Never use global polyfills, and prefer well-supported APIs when possible.
Don’t bother bundling.

Just a touch deeper:

Transpiling

The code you ship must be standard ES to “just work” for your users. Convert JSX / TypeScript / Vue SFC / other fancy syntax down to JS with babel, tsc, or whatever esbuild you enjoy, and point main to the built version instead of your raw source.

The exact ES target (ES2020 / 6 / 5) is up to you — pick a browser / node target and stick to it. Your users can transpile further down, if they’re determined, but undoing an unnecessary transform is next to impossible — it becomes bloat in the final app. Also, some babel transforms (like unicode regex) are very verbose — have a look at the generated code once in a while.

The most important question is what to do with import / export. Read on.

Tree-shaking

If your library runs in a browser, and it does more than one thing, you’d better support tree shaking — otherwise, every app using your library will ship useless dead code to the end users’ browsers. To get started, create a modular build:

Set modules: false in @babel/preset-env config to preserve import / export
Add "sideEffects": false or list your side-effect modules explicitly in package.json.
Point the non-standard module field of package.json to the resulting entrypoint.

Now a module-capable bundler can pick it up and remove unused code from the final bundle. Cool.

However, node <= 12 does not support import / export syntax without a flag. I’m lost in all the new "type": "module" / ".mjs", but shipping a fallback CommonJS build works fine in all node versions and older bundlers. For a library that works both client- and server-side, keep a CommonJS (exports / require) version (generated with a pass of babel with modules: 'commonjs'), referenced in main field of package.json.

There’s more to tree shaking — some patterns are not tree-shakable, it affects your API choices, complex topic. We’ll save for it later — supporting basic tree-shaking with ES modules is always a good start.

Polyfills

Should your library include the polyfills for recent browser APIs you use? It’s a surprisingly debatable issue among OSS authors. Problem, short version: in most app setups, babel doesn’t process node_modules, possibly breaking the final app in older browsers. But if you include a polyfill, removing it is from an app that only targets modern browsers is super hard. Also, the final bundle is likely to contain duplicate polyfills of one API.

I’ll stick with Rich Harris on this one:

Never include global polyfills that patch BuiltIn.prototype or window — they can clash with other global polyfills, and are not tree-shakable.
Use helper functions (aka ponyfills) like export function startsWith if for code reuse.
Prefer well-supported APIs if possible — using str.indexOf(...) === 0 instead of startsWith is not that hard.
Clearly say what targets you support in the readme. Don’t pretend to support IE11 if you’re not very serious. Maybe provide instructions on setting up babel-loader to process your library.

Bundling

You could bundle your code, but I think it creates more problems than it solves at the start. How to exclude your dependencies from the bundle? What libraryTarget do you need? Are we sure bundling does not accidentally create non-tree-shakable logic? I’d stick with babel CLI and ship the code as separate JS files: npx babel src --out-dir dist.

Typings

TypeScript is a major player in the JS ecosystem these days. Libraries without TS types explode in TS projects with Could not find a declaration file for module '...', forcing users to either @ts-ignore it or slap together custom ambient declarations. Some lazier developers will probably move to the next library, and I won’t blame them.

Shipping TS types is actually easy: if you write in TypeScript, tsc --declaration (--declarationOnly if you build with babel, see docs) into your build folder. If you write pure JS, it’s even easier — just write a custom index.d.ts file describing your library, and copy it to build folder. Now point types field in package.json to the declaration entry point, and you’re all set! Don’t worry about @types/* pacakges for now. See full TS docs on publishing if you have any trouble.

I don’t know much about Flow, and no one ever asked me to support it, but if you’re a fan, see SO tips on doing that.

Understand dependencies vs dev/peerDependencies

In app development dependencies (npm i) vs devDependenices (npm i --dev) is not a real issue — sure, dev is for your build pipeline, dependencies for real runtime libraries, but it mostly works fine if you mess up. The difference is critical for libraries, though:

devDependencies are not installed after npm i your-lib.
dependencies are automatically installed along with your package. If the user (or some other package) requests a different version of the same dependency, they may get duplicated, but at least it usually works.
peerDependencies allow you to reference a package explicitly installed by your users. This ensures the dependency instance is shared between user code and your library, which is crucial for plugins — react components, express middlewares, etc. In effect, this forces a single dependency version per app — your users can’t upgrade to react 18 until you support it. Assume the users have to install peers manually — sure, npm 7+ installs them automatically, but yarn and pnpm don’t. People hate manually installing stuff they don’t care about to get the project to build, so don’t overuse peers.
bundledDependencies and optionalDependencies? You don’t need them.

Basic guideline: all the runtime dependencies go into dependencies. Plugins should put the main library into peerDependencies.

Changelog

I install your library, and I’m happy with it. Some time later, it’s friday evening and I can’t get real job done any more. I decide to update my dependencies, and discover that your library moved from 1.0.3 to 2.3.0.

Have you fixed some important bugs, so that I need to update right now?
Have you added new features I might enjoy?
What’s the breaking change in v2, and how do I update?

To answer these questions, I’d love to see a changelog saying what changed in every version since 1.0.3. Both GH releases and a CHANGELOG.md in the root work fine. Otherwise, I’ll have to read the commit / PR list, which is likely to make me very sad.

So, here’s my list of stuff to keep in mind when publishing a JS library:

Must have:

A readme with a problem statement, installation command, hello world example, and full API docs.
A license: full text in project root, name in the readme and in package.json
TS typings (unless it’s a CLI tool).
Changelog in GH releases or a changelog.md.

Managing dependencies:

Runtime dependencies go into package.json
Plugins make the master library a peerDependency

Build setup:

Transpile the code to standard JS.
Running in browsers? Ship es-modules entrypoint in package.json modules for tree shaking.
Running on node? Ship CommonJS entrypoint in main.
Avoid global polyfills.
Don’t bundle.

useEffect sometimes fires before paint

Vladimir Klepov — Mon, 15 Nov 2021 12:09:54 +0000

useEffect should run after paint to prevent blocking the update. But did you know it’s not really guaranteed to fire after paint? Updating state in useLayoutEffect makes every useEffect from the same render run before paint, effectively turning them into layout effects. Confusing? Let me explain.

In a normal flow, react updates go like this:

React stuff: render virtual DOM, schedule effects, update real DOM
Call useLayoutEffect
React releases control, browser paints the new DOM
Call useEffect

React docs don’t say when, exactly, useEffect fires — it happens, quote, after layout and paint, during a deferred event. I always assumed it was a setTimeout(effect, 3), but it appears to use a MessageChannel trick, which is neat.

There is, however, a more interesting passage in the docs:

Although useEffect is deferred until after the browser has painted, it’s guaranteed to fire before any new renders. React will always flush a previous render’s effects before starting a new update.

This is a good guarantee — you can be sure no updates are missed. But it also implies that sometimes the effect fires before paint. If a) effects are flushed before a new update starts, and b) an update can start before paint, e.g. when triggered from useLayoutEffect, then the effect must be flushed before that update, which is before paint. Here’s a timeline:

React update 1: render virtual DOM, schedule effects, update DOM
Call useLayoutEffect
Update state, schedule re-render
Call useEffect
React update 2
Call useLayoutEffect from update 2
React releases control, browser paints the new DOM
Call useEffect from update 2

This is not a very rare situation — you can’t really update state in useEffect, because updating state updates the DOM, and doing so after paint leaves the user with one stale frame, resulting in noticeable flickering.

For example, let’s build a responsive input (like a fake CSS container query) that only renders the clear button if the input is wider than 300px. We need real DOM to measure the input, so we need some effect. We also don’t want the icon to appear / disappear after one frame, so the initial measurement goes into useLayoutEffect:

const ResponsiveInput = ({ onClear, ...props }) => {
  const el = useRef(); 
  const [w, setW] = useState(0); 
  const measure = () => setW(el.current.offsetWidth); 
  useLayoutEffect(() => measure(), []); 
  useEffect(() => { 
    // don't take this too seriously, say it's a ResizeObserver 
    window.addEventListener("resize", measure); 
    return () => window.removeEventListener("resize", measure);
  }, []); 
  return (
    <label>
      <input {...props} ref={el} /> 
      {w > 200 && 
        <button onClick={onClear}>clear</button>}
    </label>
  );
};

We’ve tried to delay addEventListener until after paint with useEffect, but the state update in useLayoutEffect forces it to happen before paint (see sandbox):

Now, this is not the end of the world — under some circumstances, your render flow is less optimal than it could be, who cares. Still, it’s useful to know the limitations of your tool. Here are 4 practical lessons to learn:

Don’t rely on useEffect to fire after update

Even if you know the catch, it’s very hard to make sure some useEffect is not affected by useLayoutEffect state update:

My components doesn’t useLayoutEffect. But are you sure none of the custom hooks it uses do that?
My components only uses built-in React hooks. But a uLE state update up the tree can leak through useContext or a parent re-render.
My components only has useEffect, and a memo(). But a uLE state update in the parent still appears to flush child effects.

With a lot of discipline you probably can have a codebase with no state updates in useLayoutEffect, but that’s superhuman. The best advice is not to rely on useEffect to fire after paint, just like useMemo does not guarantee 100% stable reference. If you want the user to see something painted for one frame, useEffect is not the way to do it — try double requestAnimationFrame or do the postMessage trick yourself.

Conversely, suppose you don’t listen to the good advice from React team and update DOM in useEffect. You test it, and, aha!, no flickering. Bad news — maybe it’s the result of a state update before paint. Move some code around, and it will flicker.

Don’t waste your time splitting layout effects

Following useEffect vs useLayoutEffect guidelines to the letter, we could split one logical side-effect into a layout effect to update the DOM, and a “delayed” effect, like we’ve done in our ResponsiveInput example:

// DOM update = layout effect
useLayoutEffect(() => setWidth(el.current.offsetWidth), []);
// subscription = lazy logic
useEffect(() => { 
  window.addEventListener('resize', measure); 
  return () => window.removeEventListener('resize', measure);
}, []);

However, as we now know, this does nothing — both effects are flushed before render. Besides, the separation is sloppy — if we pretend useEffect does fire after paint, are you 100% sure the element won’t resize between the effects? I’m not. Leaving all size-tracking logic in a single layoutEffect here is safer, cleaner, has the same amount of pre-paint work, and gives React one less effect to manage — pure win:

useLayoutEffect(() => { 
  setWidth(el.current.offsetWidth); 
  window.addEventListener('resize', measure);
  return () => window.removeEventListener('resize', measure);
}, []);

Don’t update state in useLayoutEffect

Good advice, but easier said than done — useEffect is a worse place to update state, because flickering is poor UX, and UX is more important than performance. Updating state during render looks dangerous. If you can, try to come up with a state model that doesn’t rely on effects, but I don’t know how to invent “good” state models on command.

Bypass state update

If you find particular useLayoutEffect causing trouble, consider bypassing state update and mutating DOM directly. That way, react doesn’t schedule an update, and needn’t flush effects eagerly. We could try:

const clearRef = useRef();
const measure = () => { 
  // No worries react, I'll handle it:
  clearRef.current.display = el.current.offsetWidth > 200 ? null : 'none';
};
useLayoutEffect(() => measure(), []);
useEffect(() => {
  window.addEventListener("resize", measure); 
  return () => window.removeEventListener("resize", measure);
}, []);
return (
  <label>
    <input {...props} ref={el} />
    <button ref={clearRef} onClick={onClear}>clear</button>
  </label>
);

I’ve explored this technique in my older post on avoiding useState, and we just got one more reason to skip react updates. Still, manually managing DOM updates is complicated and error-prone, so reserve this trick for performance-critical situations — very hot components or super-heavy useEffects.

Today we’ve discovered that useEffect sometimes executes before paint. A frequent cause is updating state in useLayoutEffect — it requests a re-render before paint, and the effect must run before that re-render. What this means for us:

Updating state in useLayoutEffect is not good for app performance. Try not to do that, but sometimes there is no good alternative.
Don’t rely on useEffect to fire after paint.
Updating DOM from useEffect will cause a visible flicker — maybe you don’t see it because of a layout effect updating state.
Extracting a part of useLayoutEffect into useEffect for performance makes no sense if you set state in the layout effect part.
One more reason to mutate the DOM from uLE manually in performance-critical cases.