DEV Community: David Lorenz

unglitch - Ultra-Simple State Management for React

David Lorenz — Mon, 05 Sep 2022 08:06:17 +0000

Stop thinking about side-effects, solve them with locked functions.

Imagine this: You create your React or Next.js setup and you need a store to seamlessly share your data across components. This will very likely include some data fetching logic which provides the data to the store.

In the old days everybody would scream Redux and you'd check with some kind of state property if fetching data was already done or is currently being done. Nowadays we have Redux + a bunch of other options - same goal, different architectures.

The existing stores are awesome, partially damn easy (e.g. zustand) and do work fine.

But (!) stores do not solve side-effect problems

The problem is that within the React Lifecycle you can have the following situation: 3 components need data, hence 3 components make use of your custom hook useData and that hook checks in the store if data is already available e.g. with

// my custom hook
function useData() {
  const data = useZustand(state => state.data);

  useEffect(() => {
    if (!data) {
     fetchData().then(/** some fetching logic **/);
    }
  }, [data]);

  return data;
}

But this is troublesome - and I am unfortunately seeing this more and more on websites: The data is being fetched multiple times, multiple requests are sent. The reason is easier explained by providing some visual help in the following diagram:

All components are using the hook useData(). And useData in that lifecycle will have empty state data. Still the useEffect() of useData() will be called 3 times as we have 3 components using it - reminder: Reused hooks are not Singletons. And the problem continues: You cannot really check the provided state data as you get the state of this lifecycle so another component might've called the fetching function but the other components will be notified in the next lifecycle run and hence also trigger fetching the data.

This is not a React problem

Now it might sound like "Isn't this bad as per architecture?". No. You get a state per lifecycle across your components such that all components will have the same, in-sync-state which is required for your components not to behave weird.

It's your problem: You need to orchestrate

At the end of the day you have to avoid that functions running outside of the React lifecycle (such as data fetching methods) will be ran multiple times. This is possible with all major State Management Libraries because they do update the state before components get notified.

E.g. in Redux (with redux-thunk) you'd have your reducer something like:

dispatch((dispatch, getState) => {
  if (getState().isFetchingData === false) {
    fetchData().then(data => dispatch({
      action: 'UPDATE_DATA', payload: data
    }));
  }
});

or in zustand you could build it like this:

const store = create((set, get) => ({
  isFetchingData: false,
  fetchData: () => {
   if (get().isFetchingData === false) {
     fetchData().then(data => set({data}));
   }
  }
}));

Works but also is additional if-overhead - and you have to remember to do it.

`unglitch` provides Lock-or-Leave calls

I wanted a simple state management solving that problem. I could've adapted zustand but then I went with digging into building an even simpler system: unglitch.

activenode / unglitch

A straightforward, unwanted-side-effect-avoiding store for React

Unglitch - another store?

Yes. React 18+ only and not planning to port to anything else. Get your sh*t up-to-date. No Context Provider needed, hooks only.

But will there be Support for Vanilla, Vue, Stencil, etc? Maybe. Not the highest prio on my roadmap but shouldn't be a big deal to provide it. Feel free to contribute.

Simple Usage

npm i unglitch

// Filename: store.ts
type GlobalState = {
  user?: {
    prename: string;
    lastname: string;
    mail?: string;
  };
};

const state: GlobalState = {
  user: {
    prename: "Spongebob",
    lastname: "Squarepants",
  },
};

export const { useStore, update } = create<GlobalState>(() => state);

// Filename: MyApp.ts
import { useStore, update } from "./store";
function App() {
  const [prename] =

…

View on GitHub

unglitch is pretty similiar to zustand and it kinda uses the same technology. However built-in with the State Management do come locked calls.

It's easiest explained with the following code snippet:

import { useStore, update } from './my-store';

const fetchData(releaseLock: () => void, realtimeData) {
  // we can check the live data outside of the lifecycle  
  if (realtimeData === null) {
    // ..fetch some data...
    // ...then update it:
    update({ data: [/** your data here */]});

    // release the lock so it can be called again
    releaseLock();
  }  
}
fetchData.LOCK_TOKEN = "FETCH_DATA";


const useData = () => {
  const [data, lockedCall] = useStore(state => state.data);

  useEffect(() => {
   lockedCall(fetchData);
  }, []); 

  return data;
}

The LOCK_TOKEN is grabbed automatically when you run the lockedCall. If the LOCK_TOKEN is not present you will be facing an error so don't worry about forgetting it. Sure, you could still manually call that function but as long as you run lockedCall it will take care of running it only once.

The function that is being called always receives a function as first parameter that will free the lock again and the second parameter is exactly the provided state data in useStore so here it is state.data.
The difference is however: The function that is being called receives the realtimeData and not the data that is currently available in the lifecycle. This allows you to check if you need to fetch data or not.

Besides this lock mechanism the store works pretty much similiar to zustand. Check it out.

The Amazon Interview Experience

David Lorenz — Mon, 28 Feb 2022 18:08:34 +0000

First I declined to write this article but I got the feedback that people are truly interested in interviewing processes about the Big Ones (FAANG = Facebook, Amazon, Apple, Netflix, Google...) so here we go ♥️

tl;dr: This Post explains how I got interviewed by Amazon and eventually got an offer.

Why I declined

Before the question pops up let me reveal upfront: The offer was legit. However I declined the Amazon offer. Simply because I had a counter-offer at the time which was kinda identical and it didn't require me to relocate - which I didn't want to in pandemic times of embracing remote work more and more (only to notice I am going to be in Home Office in a different city).

Who the F cares?

This is for people that want to understand how interviews in bigger companies work and for people that want to understand if it is "impossible" to get in. It's not. And you got not much too lose for trying.

Take it with a grain of salt

Please be aware of the fact that I report all of this from a perspective of someone that's been long time into tech. But that doesn't mean I know all the algorithms. In fact I barely know algorithms - sure it would be easy to re-learn those but I just didn't need to by now (business-wise). I'm certainly not learning any Dijkstra Algorithm by heart for an interviewing process. If they want me to then I'm out, for sure.

The Flow

I got contacted by a recruiter person for Amazon when I was working for Mercedes-Benz.io so maybe that was the reason, maybe not - who knows. But at the end of the day, the overall process would've been the same if I had applied or if you are recruited - there's no difference.
Having talked to the recruiter I was like "Yeah sure, Amazon, why not give it a try?" (I am never hyped about a job since being hyped upfront might be the mother of disappointment. Amazon and Google are also just companies with people like you and me).
The process explanation:
1. Talk to the recruiter
2. Have a Codility Test
3. Run through a Live-Coding Test
4. Meet the Team ~6 hours
5. The offer

3.1. The Recruiter Call

I don't remember every single bit of the call but the internal Recruiter was a different one than the one that initially got in touch with me. Seems like they do split the work in that regard. The Recruiter was pretty friendly and available for all questions that I had upfront. He explained that there's gonna be a Coding Test and if that succeeds they will continue. I'm honestly not sure anymore if he exactly told me WHAT kind of process will follow but I am certain he would have if I had asked.

3.2. Codility Test

Codility is a famous tool for big companies to pre-select candidates. tldr: If you fail those tests fatally there is a good chance no person will even look at it. The tasks can vary extremely in complexity and type of challenge. But these can be chosen by the company. Codility is a time-limited Challenge. This was indeed stressful for me because knowing that you have limited time and there is no one to explain to what you might be currently stuck at stressed me out. Also there is no pause button. When you start it the time runs. The timespan was 125mins. I think I finished after like 70mins but eventually left everything open to check over and over again every line of code so I stopped at around 90mins or so.

The tasks are extremely clear. There is not much room for interpretation. Of course you can google stuff but that doesn't mean that your code will get better. Take care of your code structure, make it readable and even more so code properly. E.g. if Codility says that you can assume that the input is a number then don't build something like if (isNumber). You waste your time and probably worsen your score.

Codility DOES provide a little bit of insights if you're completely wrong or not. Because there is a good amount of tests already added that you are free to run - and that really helps reassuring that you didn't code complete bullshit. But: Don't be fooled. Only because the 10 provided Tests run successfully doesn't mean that ALL TESTS will run - and you don't see all tests.

The Tasks I got weren't "out-of-universe" challenges. I felt like they were "real use-cases" which actually made the tasks fun. But still stressful.

3.3. Livecoding

Apparently my Codility challenge was very convincing so I got invited to the next step: A Coding Challenge with an actual person - Livecoding. I am not as stressed with those because meeting actual humans means that you are able to explain what you're doing. If you hate Livecoding then you will have a bad time honestly.

I am anxious as well in some situations but you simply have to get over it. There is a company that potentially wants to hire you and you have to learn to not get a blackout. It's a person in front of you, not a killer. Maybe it helps to think of Teddy Bears instead, I don't know. If you do get blackouts with all live-codings then the really only thing I can recommend is: Seek help / consult the internet for tricks to overcome it. There is a lot of lovely tips out there. Seeking help is good and no sign of weakness. Everybody has their own weaknesses.

Back to topic. The Livecoding was open for any language. The person asked me to process a few things and how I would approach certain things programmatically.

I wasn't pinpointed to JavaScript. I could have equally used Python. The online editor provided supported syntax of multiple languages. However it didn't have a "Run" button which was kinda odd for me. So you couldn't confirm if what you're doing is "correct" - but maybe that was intentionally to pinpoint you more to explanations than actual results. You have to talk and explain. Talk a lot! You can't ever talk too much. Every single step of thinking: Say it. This allows the other person to follow your steps. Don't just be quiet and say "Here that's the result".

Also I had been asked a few other questions but the recruiter prepared me upfront to read the Amazon STAR Technique (Find Info here: https://www.amazon.jobs/en-gb/landing_pages/in-person-interview). So it wasn't anything that came "unexpected" really.

Again: The Recruiter is your go-to person. See that person as your personal trainer for the processes. There is no "dumb" question - well maybe if you ask them what you should eat today, maybe that would be a "dumb" question.

3.4. Meet the Team

I was honestly right before backing off. I was told the next step would be to have several interviews in an overall timespan of 6 hours. I hate long-running interview processes. I appreciate it when companies give you options to talk but I have other stuff to do and lots of other people would've to take vacation days for that.

What did I do? I told the Recruiter. Honesty is what's important for you and the company! I said: "I don't wanna be rude but I never in my life was thrown into such a huge process and I feel like I'm backing off after the first hour if I find it intimidating or not helpful".

The Recruiter was again very nice and said "Fair points, David." and continued to explain me why they do this.

The idea behind it is to actually meet the team and have the different people in the team ask questions that might be more related to the field they are working in. Not only that but also it provides the candidate the option to get in touch with more than just the "gatekeepers of the company" (HR people).

Eventually, I found it nice because I liked the idea of meeting the team before making decisions.
But it wasn't really a meet-and-greet. It was very friendly but serious at the same time (some more serious, some funnier).

In one Interview (I think there were 6 in total, one hour each) I was asked to do a little bit of Systems Design which I found a legit task for the role I was going for (Senior Frontend Engineer).

There were never more than 2 people from Amazon in each session. Mostly one asking, one ghosting (ghosting = learning how to do interviews).

The Team also asked me questions regarding the Leadership Principles of Amazon, especially in relation to my previous experience. Since I have a lot of experience I prepared those questions very well as well as I could.

The exact questions really don't matter because they are different each time anyway but they're in the format of "When was the last time you got a difficult challenge and how did you tackle it?".

But none of it like: "Where do you see yourself in 10 billion years?" - fortunately.

If you don't have a lot of work experience it might help to find relatable experiences within your life and answer with those but I would clarify with the internal recruiter upfront. The recruiter will certainly help you out with your concerns.

At the end of the 6-hour session, I was kinda exhausted. Not in a negative way but it's still a long time in which you meet different people that all have questions.

Normally that session would've been onsite. I was lucky enough for it to be online due to the Pandemic. And I also do think they should stick with keeping it online as I find it more convenient and avoid traveling (#environment).

3.5. The Offer

The Recruiter wrote me first before sending over the offer like "David when's a good time to call you?". He said something like: "The team really liked you, you made an awesome impression and I would like to explain you the offer we have for you."

The Offer was good - especially if you consider its overall compensation package. I think it was an increase of about 15% salary as compared to my job at Mercedes-Benz.io at that time. It was slightly below my requested salary but that's okay because of what I'll explain now.

The Package included a signing bonus which would definitely cover a good part of moving costs including new furniture.

Far more interesting is the fact how they help you to get started. They want to free your thoughts from "doing all of the organizational stuff"

I would get an individual that will help me find a flat - so that person will literally take care of that so you can focus on the company - which is pretty neat.

At Amazon, you will often get additional RSUs (Restricted Stock Units). Those are Stocks from the Company which are provided to you in parts over time. So a random example of RSUs is: You get 50 RSUs promised now and you will get 10 after 6 months, another 10 after 12 months, etc. And since one Stock at Amazon is worth a lot it comes down to a very awesome compensation package the longer you stay.

RSUs are also a very good benefit keeping you in the company for a longer time.

Last but not least they will help your significant other to find a new job as well - if required. So they will make sure that you can move carefree together with your family. Which I indeed really appreciated.

Summary

I hope this helps understanding potential interviewing workflows in big companies. To understand general recommendations about interviewing please also read my other post Mastering Frontend Interviews which is definitely also for non-Frontend people.

Questions?

Post all your questions here in the comments. I'd also appreciate to connect on Twitter: Find me on Twitter @activenode

Yeah, I think that's it. Hope you liked it.

beamco.de: A new code snippet creator is in town 🌈

David Lorenz — Sun, 13 Feb 2022 20:16:44 +0000

When the sun was shining I could hardly read my own Code Snippets shared on Twitter as they lacked contrast and thickness.

I know there is carbon and ray but those didn't exactly fit my needs of a fancy theme, simplicity and readability.

So I decided to go and create a new one and here we go:

beamco.de

If you have constructive feedback and ideas for improvement please reach out to me.

`float:left` is not dead 🙇‍♂️

David Lorenz — Thu, 23 Dec 2021 10:11:03 +0000

In the Tech Community in the last few years there have been strong opinions on things. But some things are not opinions. Some things can simply be explained by facts.

One of it is the assumption that display: flex or display: grid are alternatives for floating. They are not. Period.

At this point you might think that I am crazy but let me elaborate before you agressively type comments destroying your keyboard.

display: flex is born out of a requirement that CSS hasn't solved before: Proper Layouting. In other words: Using display: block; float: ... for layouts always was a workaround. Same as in the old times when we used <table ..> for layouting.

Okay but then why should I still use `float: ...` ?

As I said: It was never built for "layouting" in the sense of what we understand as "layouting" today. Such that we have to get back to what it's actually supposed to do.

As the term float already states it is supposed to let things float (no shit sherlock) as opposed to display: flex which cannot let things float. So it's an awesome helper to wrap text around any kind of figure which makes up for a very awesome reading experience if used correctly.

The pragmatic explanation will be done via my CodePen where Drake will help you to understand better:

Reach out to me via Follow-Up Questions if you have any. 🔥

Mastering Frontend Interviews - For real

David Lorenz — Tue, 21 Dec 2021 21:32:17 +0000

Why should you even listen to me?

I am a Frontend Architect with People Management Experience (So besides the technical experience I was happy to be working together with People Management, leading peers, building up interview processes etc.)

Amazon, Mercedes-Benz.io, JvM, nodus medical and many more gave me the opportunity to work for them (meaning: I got an actual offer). Besides those few mentioned there were innumerable amounts of other interviews I was allowed to be part of - both as candidate as well as interviewer. I don't like to have tunnel vision when it comes to jobs. I do like to check opportunities from time to time because that helps me understanding the options out there as well as helps me staying in the routine of interviews.

What this post is about

This post is not about which exact weird technical challenge you should prepare for (No you don't have to learn the Quicksort implementation in 10 languages by heart other than if you are applying for a company that's name is "Quicksort in 10 languages Inc"). This is about understanding what's behind the curtains of every good interview. I won't be talking about salary in this post because salary is just something so unique that it wouldn't fit the overall context of this post.

The CV and your application letter

I appreciate your effort but honestly no one is special enough for anyone to read a book load of pages about what you've been doing and what kind of food you eat at 5am in the morning.

Most of the companies love a one page CV, one page application letter. If you say "that doesn't fit on simply one page" then you are showing your incapability of prioritisation. I know you want to show everything but the company just doesn't have the time to read the story of your life.

So if you have worked with 30 different stacks and technologies then you are very much kicking yourself out of being even invited if you list all of those next to each other. Being a FE Developer you should be highlighting your primary FE Skills. If you have worked with Cloud Technologies and Backend then that's cool but keep it short e.g. "Also I have worked with a lot of cloud and backend technologies and I love getting my hands dirty at databases".

Also don't send the exact same letter for every single position. If the role you are applying for states "You will be working on an Angular 9 Product" then it is helping you a lot if you highlight that technology first. This can obviously lead to the fact that you should mention your cloud technologies if the role specifically states that this is beneficial - if not, leave it out.

Prepare

Prepare structurally

If you get invited to an interview and the interview process is professional then the responsible person is superhappy to tell you how the interview will be structured - if you ask for it. If you don't ask for it you will literally be expecting anything.

Send them a nice mail or call them and ask "Could you tell me how the interviewing process is structured? Will there be time for questions and will there be a live challenge?" etc.

There is nothing wrong with asking how the interview will be processed and what to expect - every client can be different so every interview can have different workflows.

Prepare contentual

I remember those times of "inform yourself about what the company does". IMO this is not necessary anymore. No one will reject to hire you because you didn't know that the company has 120 employees - so forget about that stuff.

But you should still prepare and inform yourself about the company to be able to ask proper questions and hence impressing with showing your underlying motivation.
This allows both of you to see if it is a fit or not. You don't necessarily have to "lie" that you "love" the products the company creates. It is sufficient if you like its process around the development part that is part of the products - on which you will work.

If you read on the roles description: "We are a high performing team" and you feel that this sounds like "we are doing a lot of over-hours" then write it down and prepare to ask if they can clarify what "high performing team" means.

But not just that. Ask what exactly you'd be doing. That is a completely valid question. As in "So I read you are working for multiple clients here, how does a typical Frontend Coders Day/Week look like in your company?".

Also ask about the culture which helps both of you identifying if this is what you are searching for / they are searching for.

But first and foremost: Don't start asking questions in the beginning like "Ok before we start I got some questions". I did that sometimes if I felt the urge of importance but I still do not recommend it as it can have an impression of being rude if you are not being very diplomatic. So rather don't and wait for the interviewer to give you space for questions.

If the interviewer does not give you space for questions it feel encouraged to say: "Thanks for this interviewing process so far. [...] May I ask some questions about the company and the job role?".

No question is a "dumb" question if stated friendly and with honest interest.

Let's talk about Interviewing

Coders be like "Oh shit, what if I can't answer this?". And then they might fall into a deep black hole if there was a question that they felt uncomfortable with and at that point I have seen many interviews failing.

The Problem is that many don't understand what the point of interviewing is. It is checking your capabilities of solving problems at the base of your current level given the expectations that you set. That means: I can ask the EXACT same questions in an interview to a senior as to a junior but I'd be expecting completely different outcomes and both could be hired respectively.

What's the trick? Act curious instead of being challenged. Try to imagine all of it less as a "test" and more like a "tell me more discussion". And not only that. Think and explain in pseudocode if you can't provide legit facts.
Literally the worst thing you can say is "I don't know". A few "I don't know"'s and you are out. And not because you didn't know but because you showed that you aren't even trying to solve the problem - not even slightly.

Scenarios

Scenario 1: Sorting Algorithm Question

Interviewer: "Do you know which is the fastest Sorting Algorithm?"

You: "Sorry, no" - Awkward silence 🙅🏽‍♀️😐

This is close to ending the meeting soon. Here is a proposal of being curious instead:

You: "I don't have that at hand but I would love to know where the answer to this would help within your products scope if I may. I'd be assuming that JS engines would to their best to have a fast sorting algorithm. If that wouldn't be enough I would make sure to research properly how to improve the performance if there is a need detected." - 🤗

Scenario 2: `typeof null` Question

Interviewer: "Do you happen to know what typeof null is?"

Even if you know the answer to this question (it is 'object') then be rest assured that this is not a key-value test. These questions normally come with a follow up question. There is always "context" around a question.

So say you didn't know that typeof null equals object. Then the worst thing you can do is random guessing. This is not playing lotto and the interviewer doesn't like to be played. They will notice.
If you have a really good guess or you slightly remember something then explain your guess and let the interviewer follow your thoughts: Think out loud! Nothing worse than awkward silence because you think you need to think silently.

If you have no clue then simply say something like: "I am pretty sure there is a good reason you asked this. Would you mind to tell me the solution and eventually have a follow-up question on this?"

Even though not knowing you are showing your willingness to go with further questions in this context after being told the solution. A very much follow-up question probably is: "Can you imagine this check being problematic?" - Now, same rules: Start to think loud. Speak up what you think - as if you were googling. Start one by one: "Okay so if typeof null is object then that implies that a nullish/falsy value can be seen as object if checked with typeof. That means that one shouldn't check for something being an object only with typeof because it could be also null." - You are literally explaining it to yourself AND to the interviewer and hence showing your skills to solve problems at hand.

Seniors, Seniors, Seniors

There is some addendum that is important for Senior Frontend Engineers. The huge difference between Juniors and Seniors is that a Senior actually should be able to answer most of the questions asked at the expert level they present themselves with. And by that I am not saying "They must know every single property / function by heart".

What does that mean?

With Juniors I mostly ask the same kind of questions. With Seniors that's different. I know you cannot keep up with every single technology but you must be extremely proficient in a specific technology and the basics (HTML, JS, CSS) so tldr: Your primary skill of the last project + Basics.

That is why I completely adapt interviews with Seniors on-demand. I do ask the Seniors beforehand about their proficiencies. If the person is being honest saying "I think I missed out one some CSS in the last 2 years but I am really good at XYZ" then I am happy to be gentle with CSS questions and focus more on XYZ (as stated above, it's hard to keep up with everything). If a senior tells me that the proficiency lies in Angular I will focus on asking Angular-specific questions. Even if it is a position as a React Developer. The reason is simple: If the Senior can deeply elaborate on my questions considering the provided proficiency on expert level then I have no doubt that this person has the capability of understanding the architecture of another framework.

And now comes the pitfall: Seniors often don't expect me to ask basic questions which is honestly shocking for me every single time. And with basic I don't mean "Which exact CSS property will let boxes to be aligned next to each other" - it is sufficient to know that display: flex exists and that you can do a lot of alignments whichever way with it. Details: Google.

But if a senior starts telling me that float: left is a good way nowadays to align boxes then it shows that that person must've ignored every single news on the internet in the last past years.

Also one of my favourite questions for seniors is to explain me the arrow function. And if a senior says "It's a function but with a different syntax" then this is a definite reason to be rejected. For good reason: The arrow function binds context - and it binds it in a way that is unchangeable. So even the functions .bind, .apply and .call cannot change that context. But they also wouldn't throw an error. So if a senior does not know that an arrow function changes context immutably then that Senior would've a hard time debugging if there was a legacy library that would be making use of older functions but now providing arrow functions leads to problems - without throwing errors.

In my experience Seniors often oversell. So if you are insecure about being Senior then rather sell as Intermediate and surprise with potential Senior knowledge than sell as Senior and surprise with disappointment. When I do ask "How would you rank your JS knowledge on a scale from 1 to 10" they often go to 8 or 9. Because they don't do much of self-reflection anymore. That backfires. And this happens in a lot of interviews. And this is something that really only happens with Seniors, rarely with Intermediates or Juniors. The problem is that seniors are often doing something very specific in a project. And more often than never they are solving the product needs with that specific solution and that might be perfectly fine and in a way that is senior'ish. The problem is that they forget that they are often "living in a technology tunnel" without learning new things and keeping up with how JS evolves. But they must make sure to keep up with the basics.
And not just that. They also must ensure to not forget the basics. Because if they need to dig deeper (not every 3d-party library is perfectly working) they might need to be working outside of the scope of the framework with pure JavaScript. And that shouldn't be a huge challenge for them.

My suggestion here is simple: Stay humble and at least subscribe to 1 JavaScript Newsletter. That should already be a good start.

Rejection Handling

Rejections are hard. As always in life. And you must prepare for being rejected. Expect to be rejected.
And if you get rejected then see it as just one step of a potentially large but definitely finite ladder. Because every single rejection can be seen as "a practice step for the next interview". This is hard but crucial for your mental wellbeing and for getting better.

Also don't just be mad. Answer all rejections with the question for feedback: "Thank you for having invited me. Although it wasn't a fit I would be extremely happy if you could provide me more insights and feedback that will allow me to improve". You'd be surprised how much feedback you will get - Sure, there's exceptions but the worst thing that can happen is that you don't get an answer.

Feedback gives you useful insights what exactly was wrong.
Many don't ask for feedback and simply lower their self-esteem with the implication of "simply not being good enough" instead of acknowledging that it's only a step of becoming better.

A last note

Try to be yourself. Yes it can happen to "struggle" oneself into a position but that doesn't come with a bunch of happiness.

Sometimes it just isn't a fit. Everyone's different, everyone's special. Just like Friends and Relationships: Not all people bond well together. That's fine.

Phew. That was a bunch of text. I hope it helps.

JavaScript Promises tl;dr

David Lorenz — Mon, 20 Dec 2021 10:48:23 +0000

A superquick overview of Details about Promises. Stop the talk, let's start getting into it.

Promises always chain

If then or catch return a value that is NOT a promise then it will be wrapped into a new promise and chained and forwarded to the next one. That means starting from a catch you can return a value and .then it.

All of the samples here will output Hello World1

const appendWorld = s => `${s} World`;
const appendOne = s => `${s}1`;
const log = v => console.log(v);

Promise.resolve('Hello').then(appendWorld).then(appendOne).then(log);
Promise.resolve('Hello').then(v => Promise.resolve(appendWorld(v))).then(appendOne).then(log);
Promise.reject('Hello').catch(appendWorld).then(appendOne).then(log);
Promise.resolve('Blogging').then(() => 'Hello').then(appendWorld).then(appendOne).then(log)

finally

finally cannot return a value that can be chained. Kind of implied by it's name. It is called no matter if another .then or .catch was called before. When the Promise was fulfilled in any way then .finally is called. Good for cleanup work.

E.g.

Promise.reject()
  .catch(() => console.log('Catch is called'))
  .finally((s) => console.log('finally called'))

outputs

Catch is called
finally is called

Errors inside a promise are forwarded to `.catch`

Promise.resolve()
  .then(() => {})
  .then(() => { throw new Error('hey') })
  .then(() => console.log('i am never called'))
  .catch(() => console.log('error'));

Multiple `.catch` statements are useful

Promise.resolve()
  .then(() => Promise.reject())
  .catch(() => console.log('much rejection'))
  .then(() => console.log('i can continue doing stuff'))
  .then(() => Promise.reject('another one'))
  .catch(() => console.log('catching the second chain'))

`async` functions are Promise Wrappers

The following code statements have the same effect:

// async
async function foobar() {
  return 'foo';
}

// non-async
function foobar() {
  return Promise.resolve('foo');
}

`await`ing promises must be done carefully

If you await a promise then you need to be careful when checking for "success" because errors can be hidden.

See the following example:

const foobar = await Promise.reject(new Error('error thrown')).catch(error => error);

if (foobar) {
  // This does not imply success ⚠️👩‍🚀
} else {
 // This does not imply an error case
}

The problem is that the provided promise is properly caught. Referring back to promise-chaining now the result of the catch statement can be chained, hence new Error... is the resulting object if you'd call .then on it. And that is simply the same as calling await on it. So here foobar contains new Error... which is an object which when checking for if(foobar) returns true although an error was thrown. So you need to be aware of what your promises return.

`Promise.race` and `Promise.any`

Both race and any complete with the Promise whichever is first. But there is a big difference: race finishes with the first Promise to EITHER resolve OR reject whilst any finishes only with the first actually resolved Promise.

In this Promise.race sample the error Promise wins because it is first:

const promise1 = new Promise((resolve, reject) => setTimeout(reject, 100));
const promise2 = new Promise((resolve, reject) => setTimeout(resolve, 300));
Promise
  .race([promise1, promise2])
  .then(v => console.log('resolved', v))
  .catch(v => console.log('error', v));

In this Promise.any sample the resolved Promise wins because it is the first to actually resolve:

const promise1 = new Promise((resolve, reject) => setTimeout(reject, 100));
const promise2 = new Promise((resolve, reject) => setTimeout(resolve, 300));
Promise
  .any([promise1, promise2])
  .then(v => console.log('resolved', v))
  .catch(v => console.log('error', v));

Promise.all

This one is pretty intuitive: It either resolves when ALL promises are resolved OR it rejects when one of the promises is rejected.

// outputs ['one', 'two']
Promise.all([Promise.resolve('one'), Promise.resolve('two')])
.then((resultArray) => console.log(resultArray))

// outputs 'error'
Promise.all([Promise.resolve('one'), Promise.resolve('two'), Promise.reject()])
.then((resultArray) => console.log(resultArray))
.catch(() => console.log('error'))

Don't be a pr*ck: Frontend Engineers and Accessibility

David Lorenz — Mon, 20 Dec 2021 08:54:44 +0000

Basic Accessibility isn't hard and it often isn't even a choice. What's hard is your damn stubbornness.

The following code will upset you

You are a Frontend Developer. You start in a new company and you find code like this:

const data = await fetchData();
const a = [];

data.map( item => a.push({ t: item.subject, i: item._id })

Probably your first thought is: WTF is this 💣.

Let's make it nice:

const listOfTasks = await fetchTasks();
const idAndTitleList = listOfTasks
     .map(( { subject, _id } ) => ({ title: subject, id: _id }));

Did you feel the anger in the first sample?

You felt it! You felt it because it would've been so damn easy to make it clean and readable. Hence it doesn't matter "why it came to be there". It matters that obviously no one prevented this code to be merged (missing guidelines or what not) and that you suffer in a sense of Developer Experience.

Developer Experience to you is comparable to accessibility features to people that depend on it.

This is still a very much harmless example comparing how'd you feel if you were dependent on accessibility features because it wouldn't take much time on an atomic basis to improve the sites accessibility but you decided to not do it. And when the app/site is done it'd be a huge thing to adapt so you never do.

Accessibility is not hard

And often not a choice because:

If you do recommend to NOT implement proper accessibility in your application you are actually consulting for something that has legal impact in a lot of countries now. So that's, first and foremost, a very very good reason to inform yourself and your colleagues about accessibility even more.
Source: https://www.w3.org/WAI/policies/

So if you are not developing on / in / for a lonely island then there is a good chance there is legal rules for it.

I have heard this iffy saying so often. From Frontend Engineers, from Designers but especially from Product Owners and Managers trying to intrigue the engineers to "save time":

"We can do it later"

Technically I don't see a problem in "doing it later". But let me take a metaphor for it: A fork lies on your table. You can put it in the shelf right now and your room looks amazingly clean. A rush of endorphines hits your body as it comforts with the tidyness. Easygoing. Now imagine you leave everything laying around in your room for a year. Now start cleaning the room - start even finding anything. You get the point...

"People with disabilities are not the target group anyways"

This statement never holds true. Never. Not in any single case for any application that is used by more than 1 person.

I have heard this in an automotive sector often saying "blind people cannot drive so how would a11y help?".

Ehm well a blind person can still be controlling the digital sales part of the automotive sector. Just to have a very, very clear example. I could add thousands more if you want.

Also bad accessibility always impacts pro users because it often comes with bad keyboard usage.

"Okay I'll add an `aria-label` and some `alt` attributes"

Fk no. No no no. Don't just start adding random aria-* attributes or alt/title tags if you do not know the impact. Start with the basics of understanding. Understanding is the crucial point of effortlessly using it and implementing it whilst coding. I would recommend myself but the problem is that I don't have any public sources on my own so I would need to lend you my brain.

There is an extremely good free udacity course from Google (I really, really can recommend this): https://www.udacity.com/course/web-accessibility--ud891
Read this: https://developers.google.com/web/fundamentals/accessibility/semantics-builtin/the-accessibility-tree
Also you can start off at Sara Soueidan. She also has published a new course which you will find a link on her Twitter account to.
A good read is always MDN e.g. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/heading_role

Let me prove how easy it can be to improve Accessibility

Understand that CSS impacts a11y: If you do display: none on an element it is hidden both visually as well as in the Accessibility Tree so your <div style="display: none" aria-label="additional info only for screen readers">... is useless.
Ensure good ratio on your designs (built-in in the chrome inspector; there is also a lot of Sketch plugins for Designers e.g.) ; https://webaim.org/resources/contrastchecker/
Using a proper HTML structure is a very good start. HTML by definition (without adding CSS etc.) is perfectly accessible if correctly used. https://developer.mozilla.org/en-US/docs/Learn/Accessibility/HTML
If you have fancy elements on your side that literally have no effect but looking cool (so content-wise not relevant) then simply hide em' semantically with aria-hidden="true"
The alt attribute on a img tag is nothing that necessarily needs content. It needs content if the image shown is connected to the content. E.g.: You have a news article and you report about "More and more people visit the new shopping center". Now imagine there is an img tag with a photo showing a lot of people in the shopping center. Then a good alt tag would be alt="A lot of people standing in the new Shopping Center the city" . If however the image is just a random stock picture then it doesn't provide additional information and you should have alt="" (in this case the content lives for itself and the image is just a visual addendum).
If you use modals, make sure to "Lock In". If you cannot click elements below the Modal with your mouse then you shouldn't be able to tab with your keyboard below it. But many modals do that and it's horrible for people working with screen readers because they often cannot get back to the modal once they left it. I also built one React Library to help with that: https://github.com/activenode/react-use-focus-trap

Now stop being a prick and at least inform yourself a little bit.

Providing a good semantic HTML structure, knowing how and when to properly set alt attributes (most FE Developers think they know this but in fact they don't) and the impact of using aria-* attributes can be a very good start for having basic a11y. That doesn't sound like a huge effort, does it?

⚡️HTML is not a programming language

David Lorenz — Wed, 24 Nov 2021 09:35:26 +0000

Btw, CSS also isn't a programming language. I know what you think: I'm gonna put some roast on this iffy post from this arrogant guy who is trying to talk down the language.

First and foremost: If you only code in HTML you are a programmer, no discussion needed ♥️. The definition of a language does not change your worthiness or your job title.

Let me elaborate why writing this blogpost is important and essential and why it is not about "being right". My assumption is that the discussion is purely based on insecurities and fear.

Why do you even care?

People on twitter seem to fight for the right that HTML is a programming language. The essential question is why do people argue about it? I don't get it. The definition of what HTML is does not change anything about the fact that HTML is the crucial language to create websites and web apps - fact.

People confuse programming language and being a programmer

Maybe that is one of the fears that people have: If neither HTML nor CSS is a programming language then am I even a programmer by just using HTML/CSS? Sure thing, you are! Even though the word has the same origin being a programmer and programming language are still different things.

Let's take the Wikipedia Definition:

A computer programmer, sometimes called a software developer, a programmer or more recently a coder (especially in more informal contexts), is a person who creates computer software.

So even if you do not code at all e.g. by designing systems architecture you are part of the programmers world.

Why it is important to acknowledge that HTML is not a programming language?

In very simple words: Because if we go by the majority of scientifical definitions then it is often described as a Markup Language (HTML= Hypertext Markup Language) as opposed to programming language. We are living in a world that often confuses facts with opinions and hence create problematic discussions that wouldn't even be worth the energy simply because it does not change a single thing about the outcome.

Let's face Wikipedia again:

Markup languages like XML, HTML, or troff, which define structured data, are not usually considered programming languages.
Source: https://en.wikipedia.org/wiki/Programming_language

There is a "trivial" and a not-so-trivial explanation. The not-so-trivial one is about language possibilities, turing completeness and so on and so forth which I do not want to elaborate in detail here because.
A more trivial approach is: If you can build a calculator based on users input with it then it most likely can be considered a programming language. Bash can do that, JS can do that, HTML cannot. You can define input fields in HTML but HTML cannot process them and sum/multiply. CSS can partially calculate but then again it is extremely constrained to "hardcoded" values and not arbitrary input.

And by the way: SQL can also only calculate things to a constrained extent. You cannot write a full program in SQL. SQL is a declarative language. But back to the actual point: Why would you care to make it a "programming language"? You are a programmer nevertheless.

Conclusion:

I am not trying to be "right". That is not the whole point of this post. Generically spoken I would really love to see a world where we come together and share what's available in science rather than creating an "opinion" about things that science has a clearer view on. That can be troublesome in any topic e.g. vaccination.

A good start here is to ask questions: "Can you provide me some more information why HTML wouldn't be considered a programming language?" or vice versa.

That is the world that I am looking for. A proper, scientifically based discussion (how they are very often found in good responses on StackOverflow).

I just do not get the point why a simple word triggers so many people.

Peace & Love
David

Don't use CSS classes for testing in Unit Tests or E2E

David Lorenz — Fri, 12 Nov 2021 11:18:08 +0000

CSS is meant to style your elements. Sometimes you do that via class and sometimes there is elements that want to be styled the same way all the time e.g. h1.

In my past experience I have seen a lot of projects that write their tests depending on css classes. Although this works it is architecturally not the finest of the finest.

Let's face following problem:

<article class="article">
 <strong class="article__title">Whatever</strong>
 <p>Some text</p>
</article>

Now your task is to test if the "Whatever" is contained.

In your tests you might be doing something like on of these options:

// Option 1:
expect(...query('strong').innerText.trim()).toBe('Whatever');

// Option 2
expect(...query('.article__title').innerText.trim()).toBe('Whatever');

The first option is probably the worst since it means that changing the strong to e.g. em or h2 you would need to adapt that in the test as well.

The second option with querying article__title class is more stable. But also only if you are using this exact semantical BEM approach. If you use something like Tailwind or bootstrap are you then going to search for whatever-xl-highlight class?

⚡️ Both options are not stable for changes!

The stable option is to add semantic probe identifiers.

<article data-probe-id="blogpost">
  <strong data-probe-id="blogpost__title">

Now whatever changes stylewise, removing classes, adding classes, changing class names, the probe-id will stay and make the life of your Teast team easier as it rarely needs to adapt.

Also what comes in handy in Test-Driven-Development is that the Test Team can define the probe-id values upfront before implementation.

Problem solved 🚀

The Breakpoint CSS-JS "Hack" - do not define breakpoints in JS

David Lorenz — Thu, 11 Feb 2021 10:21:40 +0000

This trick is a best practice trick. Knowing that this is a best practice I thought this is a common thing but apparently it is not as widespread as I thought it would be.

So let me share it with you.

Do not redefine your breakpoints in JavaScript/TypeScript

I am assuming you are using either native CSS or SASS for your development so let's use SASS for my code snippets now.

Assume your breakpoints are defined as follows:

mobile => max-width: 599.99px
tablet => min-width: 600px

Now what some people do is redefining those values in JS. But you can simply read the current breakpoint directly from CSS. Also you can pass all breakpoints through CSS as Single Source of Truth for UI ♥️

The trick is to use the :before in combination with content :

@media screen and (max-width: 599.99px) {
  body::before {
   content: "mobile";
  }
}

@media screen and (min-width: 600px) {
  body::before {
   content: "tablet";
  }
}

You can access this in JS via getComputedStyle(document.body, 'before').content and it would give you e.g. "mobile" or "tablet" here. So the only thing left to do is to remove the quotes like so:

const breakpoint = 
  getComputedStyle(
    document.body, 
    'before'
  )
  .content
  .replace(/"/g, '');

Now if you want to have all definitions from CSS you could do something like this:

.media-queries::before {
  display: none;
  content: "mobile=(max-width: 599.99px);tablet=(min-width: 600px)";
}

Now you can read that content and use actually matchMedia or whatever you want but the important part is to always have the Design in CSS and not duplicated in JS.

Here is an actual demo you can check out:
https://codesandbox.io/s/reading-media-queries-bps-from-css-06zjh?file=/index.html

Angular 10 + Storybook + npm package = NG Design System 💜 - Step-by-Step

David Lorenz — Thu, 15 Oct 2020 15:54:24 +0000

! The Angular version used here is 10.x

tldr - The Task was:

Create a UI Kit with Angular that lives on its own and scales to multiple product usage.

Or in technical terms:

npm i @your-company/your-ui-kit

import { Button } from '@your-company/your-ui-kit'

The Final Result:

Angular-based library published as @your-prefix/pattern-lib
Using Storybook to preview the library elements
Using and exporting global scss styles

1. Background and Decision-Making 👨🏽‍💻

Our product application is based on Angular. We wanted it to scale such that we can quickly re-use components even across other products.
Those components should always go with the Brand visuals.

To achieve that we wanted to do what the de-facto standard is: Creating a Design System that is implemented as a Pattern Library (furthermore called Pattern Lib)

1.1. A "No" to Web Components and a "Yes" to NG components 👀

If you follow me on different channels you know that I love Web Components. But:

Use the right tool for the right job 🛠

At Mercedes-Benz.io we were using Web Components together with Stencil to create the Pattern Library. This decision was based on the fact that we had React, Vue, Angular and partially even Elm in our product stack and therefore needed to find a Library approach that is framework independent.

However being framework independent comes with the downside of not getting the best from that very framework since you are mixing up different technologies - that can especially get messy once your requirement says: Enable SSR.

So at the end of the day: You have the balance the upsides and downsides based on how your business is built.

The process that led to an Angular-based PatternLib

Angular does a lot of preprocessing in its compilation process. So the compiler ensures the best overall output is achieved - when using Angular. Angular cannot optimize the code you put in your Web Component.
Maintaining a framework-agnostic solution makes only sense if you plan to support multiple frameworks in the long run.
Small team: Focus switch avoidance between e.g. Stencil and Angular. Sticking with Angular delivers overall better output since we can apply the same guidelines.
You do not necessarily benefit of awesome Editor help when mixing up 2 technologies - or you have to put in more of work to achieve that.
If you still want to output Web Components from your library you will still be able to tune up your build to do so.

2. How to implement an Angular UI Kit / NG UI Library

2.1. The Pre-setup

I guess it is clear that you will have to have @angular/cli installed and ready.

Besides that: The first thing you want to do is to be able to test your library to confirm that you did a good job. So before we create the actual library we want to create the application that consumes it.

ng new my-app --prefix=ma --style=scss --legacyBrowsers=true

We use the prefix to be safe and isolated from any used library (that might be unprefixed).
You do not need legacyBrowsers if you do not plan to support IE.

2.2. Creating the library

Run the following command in the directory where your my-app is located (so basically in its parent directory ./my-app/../).

ng new design-system --create-application=false --prefix=ds --style=scss

Important Note: In Angular 10.1.4 that I used for this project the --style=scss did not have any effect. This comes from the fact that we created an empty application and Angular has no option yet to predefine it (we will fix it soon in this tutorial).

We call the parent design-system to not get confused with its child module below.
Now your directory structure should look like this:

.
├── my-app
├── design-system

Inside your design-system directory we now create the actual library that will contain our components:

ng generate library pattern-lib --prefix=pl

First thing you want to do is to make the package scoped to easier identify it is your library.

So go to design-system/projects/pattern-lib/package.json and change the name from pattern-lib to @your-company/pattern-lib .

As said above: We also have to fix --style=scss on our own since this is not yet possible to define for a library or empty application upfront. Do the following:

Go to design-system/angular.json
Search for your added library in "projects": { ...}
Add the schematics property to your projects/pattern-lib

In my project it then looks somewhat like this:

...
"projects": {
    "pattern-lib": {
      "projectType": "library",
      "schematics": {
        "@schematics/angular:component": {
          "style": "scss"
        }
      },
...

2.3. Creating a `button` component in the library

ng generate component button --project=pattern-lib

This command will create a component named button. Your directory structure should contain the following directories:

.
├── my-app
├── design-system
   ├── projects
      ├── pattern- lib
         ├── src
            ├── lib
               ├── button

You might want to say: Yo David why so many subfolders? Can't I just put it in the root src?

Answer: Angular allows to control multiple libraries / components / modules etc. in one Angular project root and the @angular/cli is optimized to suppor this exact structure. If we start building a pattern lib in a default ng new my-pattern-lib application -> that will work for sure but we are leaving the safe track to a slippery path because then we have to bend the tools to do what we want to do (expose and publish library parts).

Open up button.component.ts and make sure it has 2 properties defined in the class like this:

import { Component, OnInit, Input } from '@angular/core';

@Component({
  selector: 'pl-button', // pl is our prefix
  templateUrl: './button.component.html',
  styleUrls: ['./button.component.css']
})
export class ButtonComponent implements OnInit {
  @Input('label') label: string | null;
  @Input('pink') pink: boolean;

  constructor() { }

  ngOnInit(): void {
  }

}

Quick explainer: By setting the properties explicitly (e.g. @Input('pink') pink: boolean;) the component exposes its editable fields which will come in handy in Storybook later since Storybook can autodetect the field types.

Now open button.component.html and fill it with:

<button [attr.is-pink]="pink" [ngClass]="{'make-pink': pink}">{{label ? "😎 " + label : "No Label provided 🧐"}}</button>

The [attr.is-pink]="pink" we use to debug if we run into errors. It is not needed though 😉

Also open button.component.scss and fill it with:

button {
  background: blue;
  padding: 1rem 2rem;
  border-radius: 3px;
  appearance: none;
  border: 0;
  -webkit-appearance: none;
  -moz-appearance: none;
  font-size: 1.5rem;
  letter-spacing: 1px;
  color: white;
  box-shadow: 0 4px 10px rgba(55, 55, 55, 0.3),
    0 6px 35px rgba(55, 55, 200, 0.7);
  cursor: pointer;

  &.make-pink {
    background: #ff00a2;
    box-shadow: 0 4px 10px rgba(55, 55, 55, 0.3), 0 6px 35px rgb(200 55 150 / 70%);
  }
}

Now you want to build and see the button in action - but it is just a library, not an SPA, so HOW?

2.4. Run it: Storybook to the rescue.

Adding storybook normally is quite easy as there are ready-to-go recipes. However these do not naturally apply for an Angular library.

2.4.1. Installing Storybook and binding it to our Library

Run npx -p @storybook/cli sb init --type angular within your design-system Angular project.
Open .storybook/tsconfig.json and change the extends line to "extends": "../projects/pattern-lib/tsconfig.lib.json" (if not already set)

2.4.2. Setting up our button story

Go to design-system/stories and DELETE EVERYTHING
Create a file named Intro.stories.mdx with following content:

import { Meta } from '@storybook/addon-docs/blocks';

<Meta title="Library Example/Intro" />

<style>{`
  .box {
    margin: 2rem 0;
    padding: 2rem;
    background: rgba(233,233,233,0.7);
    border-radius: 3px;
  }
`}</style>

# Hello you!

<div class="box">
  This is the Pattern Library Intro File to provide a guiding path or whatever else you want to do here. Feel free!
</div>

![](https://media.giphy.com/media/yJFeycRK2DB4c/giphy.gif)

Create a file named Button.stories.mdx with following content:

import { Story, Meta } from '@storybook/angular/types-6-0';
import { ButtonComponent } from '../projects/pattern-lib/src/lib/button/button.component';

export default {
  title: 'Atomics/Buttons',
  component: ButtonComponent,
  argTypes: {
    label: { control: 'text' }, 
    // we need to override here since in Angular it could be null as well (see button.component.ts) and therefore it would become an ambigious data type for storybook
  }
} as Meta;

const Template: Story<ButtonComponent> = (args: ButtonComponent) => ({
  component: ButtonComponent,
  props: args,
});

export const FancyBlueButton = Template.bind({});
FancyBlueButton.args = {
  label: 'Button',
};

export const FancyPinkButton = Template.bind({});
FancyPinkButton.args = {
  label: 'Pink version',
  pink: true,
};

2.4.3. Run, run, run!

Trigger npm run storybook within your design-system project folder and wait for it to - hopefully successfully - boot up.

As a result you should see something like this:

Cool Stuff!

Quick Summary: Up to this point we created an Angular library with a button as a component and connected Storybook to it to be able to see and structure it without running an actual Angular SPA.

2.5. Global SCSS and Component Composition

2.5.1. Global SCSS

Go to design-system/projects/pattern-lib/src/
Create a directory styles/
Create a file named global.scss with some random content e.g. body { background: red }

Use it in Storybook

To make sure that Storybook can apply the global scss head over to .storybook/preview.js and add it as a webpack import like this:

import '!style-loader!css-loader!sass-loader!./../projects/pattern-lib/src/styles/global.scss';

That's it. Storybook will now always use that file as a global file for every view.

Use it in Angular

Using a global SCSS in Angular shouldn't be a problem since you can always @import it in any of your SCSS files in your project e.g. like

@import '../../styles/global';

However >> WARNING: Make sure not to import actual CSS definitions such as body { background: red } into your Angular components as those would get duplicated and would drastically decrease performance.

If you want a global CSS file for your Angular App you can (and should) surely define it in your library but you should export them with the npm package (see section 2.6.) such that your Angular SPA can then include it.

In any Angular application (!= Angular library) you can add this to the angular.json to define a global style for the App:

"styles": [
  "node_modules/@your-company/pattern-lib/styles/style.scss"
],

2.5.2. Component Composition

Please refer to https://www.learnstorybook.com/intro-to-storybook/angular/en/composite-component/ if you wanted to combine multiple components in Storybook.

2.6. Using the `pattern-lib` in your Angular application `my-app`

Now what we want is to be able to use our patterns in any application that we create - as an npm package.

The following diagram visualizes that:

Hold up! Important!

Before we use our library we need to import the CommonModule from @angular/common as otherwise our [ngClass] binding of our button will not work (more info here: https://stackoverflow.com/a/45573086).

So in design-system/pattern-lib open up pattern-lib.module.ts and adapt it such that you do:

//... other imports
import { CommonModule } from '@angular/common';

@NgModule({
  ...
  imports: [
    CommonModule
  ],
  ...
})

2.6.1. Export the button for usage

If we want our button to be usable outside of the library we need to export it in our pattern-lib.module.ts like this:

//.. other imports
import { ButtonComponent } from './button/button.component';


@NgModule({
  ...
  exports: [PatternLibComponent, ButtonComponent]
})

2.6.2. Using the library package through local binding

Go to the directory design-system and run

ng build --project=pattern-lib

Head over to design-system/dist/pattern-lib and run npm link.

Now your package should be available on your computer under its package name @your-company/pattern-lib.

No go over to your Angular SPA my-app and run npm link @your-company/pattern-lib. This basically is like a local npm install - however it will not show up in your package.json. Alternatively you can also do npm install ../design-system/dist/pattern-lib if you prefer so.

Add the linked library to our `my-app`

Go to my-app/src/app/app.module.ts and add the library import

import { PatternLibModule } from '@your-company/pattern-lib';

Also add it to the imports field of app.module.ts:

@NgModule({
  ...
  imports: [
    ...
    PatternLibModule,
  ],
  ...
})

Go to my-app/src/app/app.component.html and delete all the contents and put the following instead:

<style>
  :host {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
    font-size: 14px;
    color: #333;
    box-sizing: border-box;
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
  }
</style>


<div>
  <p>Hello I am the Angular SPA and following a button should be shown and it should be blue: </p>
  <dvpl-button label="hello"></dvpl-button>

  <p>And this one should be pink: </p>
  <dvpl-button label="Hello pink?" [pink]="true"></dvpl-button>
</div>

<!-- you only need this if you added a router: -->
<router-outlet></router-outlet>

Now you should be able to run npm start in your my-app SPA and you should see that your Angular application properly makes use of our library.

2.6.3. Using the package with an `npm` registry

Now that you have it already running locally this should come with ease.

First things first. Choose a npm registry (e.g. Github or npmjs).
Create an .npmrc file in your design-system Angular root that looks similiar to the following:

registry=https://registry.npmjs.org/
always-auth=true
email=YOUR_EMAIL_GOES_HERE

Login with npm login - It should ask you for your credentials on the registry provided in the .npmrc file.
Once you are logged in you can simply run npm publish in your design-system/dist/pattern-lib directory to publish the library that you built! Make sure to NOT run it in your root directory but really in dist ! Because if you run npm publish in your root directory it will only publish all the source code and not the compiled library.
Now you can use it the same way you installed it locally but from the given repository with npm install @your-company/pattern-lib 🎉

3. Testing Storybook, atomic imports and Web Components, etc.

There is way more that we could discuss - but I don't wanna excess this here too much: How to not only test the components but test them with Storybook, how to export more atomically (a single Button import instead of the whole library if needed) and publishing for other Frameworks as a Web Component.

But this might be worth another Blog Post. Let me know!

4. Conclusion

You created a Design System Repo with Angular and you are able to publish it in different versions.
Also you can use them in whatever Angular app you want 😎.

Find the source code of the sample here:

activenode / angular-10-storybook-library

An angular library to implement an isolated Design System

Angular 10.x Storybook Library

This is a sample repository that includes 2 Angular root-projects.

design-system which is an angular project containing UI elements (pattern library)
my-app which consumes those

This is the final result of the step-by-step tutorial provided at dev.to: https://dev.to/activenode/angular-10-storybook-npm-package-ng-design-system-step-by-step-2dn2

View on GitHub

Sources:

Design References:
Packaging Design Icon made xnimrodx from flaticon.com

srcset, sizes, picture, media: What you might not have known.

David Lorenz — Tue, 29 Sep 2020 12:04:11 +0000

Gosh. Yet another "How-To Responsive Images" article? Well nope, I hope.

The background story: It all started with an `<img>` tag

So one of my colleagues was going like

WTF Dude, Firefox is loading some bunch of huge images even though I provided a proper srcset and sizes attribute.

In 20 years of programming experience - also in these modern times - me and the team have seen some weird browser bugs here and there so I do not immediately assume the problem is the one in front of the computer.

However in this case, for something so crucial I and rather simple I couldn't believe it's a Browser problem. Especially as Safari was behaving the same way.

It was something like this:

<img src="raw.jpg"  
srcset="360w.jpg 360w, 800w.jpg 800w, 1080w.jpg 1080w" 
sizes="
  (max-width: 360px) 360px,
  (max-width: 800px) 800px,
  (max-width: 1080px) 1080px
">

For a Samsung Galaxy S9 with 360x740 it would load the 1080px one. And we both were a bit confused.

I don't want to create cliffhangers so I will immediately jump to the problem: The S9 has a 4x density as its actual resolution is way more than the above. It is 1440x2960 (h x w). So yeah, divide that by 4 and you will get 360x740.

Now what the browser did was quite clever:

Yo Dog, I know you wanted 360w image on 360px screen but this equals 100% width on this mobile phone which is actually 1440px to have a sharp view so I will choose the closest that fits that image size which is 1080px

It is not directly "intuitive" but it makes sense

It makes sense when you think about it. But for that you have to accept the fact that an img tag with srcset is something where you give the browser options (we will have a closer look on this). You are not necessarily the Director of the scene. If the browser thinks that a certain image out of the provided ones in srcset is the best fit according to the given information then it will choose that image.

So what was the solution now?

We now know what happened and why it happened and I love to tell you the solution - but it really depends on what you want to achieve.

In this specific case he wanted to deliver a specific image depending on the width of the device. So what he could've done (not saying should've done) to deliver the image that he actually wanted is the following:

Before:

<img src="raw.jpg"  
srcset="360w.jpg 360w, 800w.jpg 800w, 1080w.jpg 1080w" 
sizes="
  (max-width: 360px) 360px,
  (max-width: 800px) 800px,
  (max-width: 1080px) 1080px
">

After:

<img src="raw.jpg"  
srcset="360w.jpg 360w, 800w.jpg 800w, 1080w.jpg 1080w" 
sizes="
  ((max-width: 360px) and (-webkit-min-device-pixel-ratio: 4)) 90px,
  ...
  (max-width: 800px) 800px,
  (max-width: 1080px) 1080px
">

So 360/4 = 90px so when the Browser will search for the best image fit now it will go "Okay I need a 4 times bigger image than 90px which is 360px so I am taking the 360w.jpg"

That does not sound like a clean solution does it? Especially when you think about the fact that you would also intentionally deliver an image with non-fitting quality (4 times less the quality to be exact).
However the next time a 5x or 6x DPI device hits the market you need to adapt more and more in your queries of the sizes attribute.

David you talked a lot about the issues but what would you recommend?

I recommend: Start with thinking what you want to see as an end-result. Maybe even draw it on paper. Then continue to think which solution will help you to achieve that and it might not be an img tag with srcset but maybe the picture tag instead. Please read the explanations below for that.

If its the same image on all devices no matter what but with different sizes you should go for using Retina definitions in your srcset:

<img src="raw.jpg"  
srcset="
  image.jpg,
  image@2x.jpx 2x,
  image@3x.jpx 3x,
  image@4x.jpx 4x,
  image@5x.jpx 5x">

It is all about understanding the specs

`img`: The important specification details on `srcset` + `sizes`

If you use srcset="foo.jpg 200w ..." then you MUST (check the W3C specs) provide a sizes attribute to tell the browser "On this media query the image will have a shown size of WHATEVERpx".

If you use srcset="foo.jpg 2x ..." you MUST NOT provide a sizes attribute. The browser would just ignore it as it implies the chosen image only by the pixel density.

According to https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element (09/2020) the img tag does not support the attributes media, type. Which is understandable if you read the following paragraphs about picture and its source tags.

The powerful `picture` tag and its `source` children

Semantically, (reading the W3C specs) the picture element is just a "ghost" container for the img tag that allows to control what image is served in the img tag.

W3C states:

The picture element is a container which provides multiple sources to its contained img element to allow authors to declaratively control or give hints to the user agent about which image resource to use, based on the screen pixel density, viewport size, image format, and other factors. It represents its children.

MDN describes the picture tag as the tag for the goal of Art Direction. What they mean is: Total Flexibility. The big difference to img[srcset][sizes] is that you do not let the browser choose which is the best fit for the device size. You explicitly define what image shall be played under what exact circumstances (media query). This can be based on pixel density, screen ratio, height, whatever you want.

The picture element must at least contain an img tag and for it to be actually useful it should contain 1 or more source tags.

Let us go by examples.

1. Retina Image with `picture` tag

We simply want to scale up the images depending on device pixel density.

<picture>
 <source srcset="logo.png 1x, logo_x2.png 2x, logo_x3.png 3x">
 <img src="logo.png" alt="Cool Logo 👌">
</picture>

This sample could be seen as over-engineered since removing the picture and source tag but keeping the img tag would do the same thing:

<img src="logo.png" alt="Cool Logo 👌" 
  srcset="logo.png 1x, logo_x2.png 2x, logo_x3.png 3x">

2. Choosing a different image depending on ratio

<picture>
 <source 
  media="(min-aspect-ratio: 21/9)"
  srcset="2100x900px-img.jpg">
<source 
  media="(min-aspect-ratio: 16/9)" 
  srcset="1600x900px-img.jpg">
<source 
  media="(min-aspect-ratio: 1)" 
  srcset="300x300px-img.jpg">
 <img src="fallback_whatever.png" alt="💞">
</picture>

The above will solely take the aspect ratio of the screen into account. So for a 600x600 screen with actual resolution of 3000x3000 which would be 5x retina it would still use the 300x300px-img.jpg because that is the first media query that matches.

This is important to note: source tags are matched from top to bottom. If one hits, the following are ignored.

2. Choosing a different image depending on ratio whilst still providing proper retina images

<picture>
 <source 
  media="(min-aspect-ratio: 21/9)"
  srcset="
   2100x900px-img.jpg 1x, 
   4200x1800px-img.jpg 2x,
   6300x2700px-img.jpg 3x">
<source 
  media="(min-aspect-ratio: 16/9)" 
  srcset="
   1600x900px-img.jpg 1x,
   3200x1800px-img.jpg 2x,
   4800x2700px-img.jpg 3x,">
<source 
  media="(min-aspect-ratio: 1)" 
  srcset="
   300x300px-img.jpg 1x,
   600x600px-img.jpg 2x,
   900x900px-img.jpg 3x">
 <img src="fallback_whatever.png" alt="💞">
</picture>

The only difference to our previous sample now is that we tell the browser exactly which source tag to take but then the browser is able to choose the best image within this source tag. So if its 8x retina but a squared screen it would hit the last source tag and choose the next best fit which is 3x which is 900x900px-img.jpg.

3. Improving performance with `source` tag and `type` attribute

Let us take a simple sample and tune it only for the sake of performance with the type attribute.

Before tuning:

<picture>
 <source 
  media="(min-width: 1024px)"
  srcset="
   big.jpg 1x, 
   big-2x.jpg 2x">
<source 
  media="(min-width: 768px)"
  srcset="
   medium.jpg 1x, 
   medium-2x.jpg 2x">
 <img src="fallback.jpg" 
  srcset="
   fallback.jpg 1x, 
   fallback-2x.jpg 2x" alt="💞">
</picture>

As you can see we have 3 potential sources. It is totally okay to also use srcset on the img within a picture tag as it will only be considered when the other 2 source tags are not matched.

The W3C says:

The srcset attribute and the src attribute (if width descriptors are not used) contribute the image sources to the source set (if no source element was selected).

Let's tune:

<picture>
 <source 
  media="(min-width: 1024px)"
  type="image/webp"
  srcset="
   big-optimized.webp 1x, 
   big-optimized-2x.webp 2x">
 <source 
  media="(min-width: 1024px)"
  srcset="
   big.jpg 1x, 
   big-2x.jpg 2x">
 <source 
  media="(min-width: 768px)"
  type="image/webp"
  srcset="
   medium-optimized.webp 1x, 
   medium-optimized-2x.webp 2x">
 <source 
  media="(min-width: 768px)"
  srcset="
   medium.jpg 1x, 
   medium-2x.jpg 2x">
 <source 
  type="image/webp"
  srcset="
   fallback-optimized.webp 1x, 
   fallback-optimized-2x.webp 2x">
 <img src="fallback.jpg" 
  srcset="
   fallback.jpg 1x, 
   fallback-2x.jpg 2x" alt="💞">
</picture>

Now we not only provided different images for different resolutions but we also provided the browser the possibility to then take the retina image and of that even the optimized version in the webp format instead of jpg.

`picture` tag Conclusion

The picture tag allows you to play a different image in different situations. E.g. if you were going to play a moving .gif file but you want to improve A11y you could do something like:

<picture>
 <source 
  media="(prefers-reduced-motion: reduce)"
  srcset="
   no-motion.jpg 1x, 
   no-motion2x.jpg 2x,
   no-motion3x.jpg 1x 3x">
 <img src="funny_moving_gif.gif" alt="Funny Animals">
</picture>

Conclusion: So when to use what?

`picture`

If you have a complex setup do yourself a favor, use picture.

`<img srcset sizes ...>`

If you have an image that stays the same ratio but shall be played in different quality versions e.g. actual Photographs such as those uploaded on Instagram or Facebook then you might would want to simplify your life by using <img srcset> or <img srcset sizes> depending on what you want to achieve.

Use the comments below for any questions.