Formalizing REST APIs

My API is up to level 2 on the Richardson Maturity Model. So my API is more an HTTP+JSON RPC than Rest.

The short answer to this question is that HATEOAS isn’t a good fit for most modern use cases for APIs. That is why after almost 20 years, HATEOAS still hasn’t gained wide adoption among developers. GraphQL on the other hand is spreading like wildfire because it solves real-world problems. ‒ GraphQL and REST Level 3 (HATEOAS)

I feel this feeling too that something is wrong

Without auto, the remains 4 / 3, and the image appears stretched. You can avoid the stretching with object-fit:

img {
  aspect-ratio: 4 / 3;
  width: 100%;
  object-fit: cover;
}

Although, if the image isn't actually that aspect ratio, it'll either end up stretched (object-fit: fill), letter-boxed (object-fit: contain), or cropped (object-fit: cover). None of which are ideal.

Using clip-path to define custom shapes inside a container!
Percentages units has the benefit of keeping things responsive
There is many clip-path functions: inset, circle, ellipse, polygon and... path for maximum flexibility

clip-path: inset(x x x x) is useful for clipping blocks of an element and using it as a "controlled" overflow.
This clip-path value represents a thunderbolt: polygon(100% 0, 20% 50%, 35% 50%, 0% 100%, 70% 50%, 50% 50%)

We can transition or animate clip-path. There's one condition. The path must have a consistent structure. For example, if we transition a polygon, that polygon must have a consistent number of points.

Skewing effect: https://codepen.io/enbee81/pen/yLyrmyg

and cyberpunk buttons in CSS: https://jhey.dev/writing/css-cyberpunk-2077-buttons-taking-your-css-to-night-city/

Creating patterns for imgs

This size matches the dimensions of our SVG exports. This is important. This is the one drawback of using clip-path: path(). It's not responsive. The path definition is relative to the dimensions of your element.

Changing the shape:

.portrait {
  transition: clip-path 0.2s, transform 0.2s;
  transform: scale(var(--scale, 1)) rotate(var(--rotate, 0deg));
  clip-path: path(var(--clip, var(--splat)));
}
.portrait:hover {
  --scale: 1.15;
  --rotate: 30deg;
  --clip: var(--splattier);
}
.portrait:active {
  --scale: 0.85;
  --rotate: -10deg;
  --clip: var(--splatted);
}

Creational

Singleton

Type of object that can be instantiated once

In Typescript, just use a global object, so you don't have the boilerplate.

Prototype

Object.getPrototypeOf

Builder

Build object step by step through different methods instead of using many parameters

Factory

Determine which object to instantiate

Structural

Facade

Simplified to hide low-level details of a system

Proxy

Reactivity system of Vue :D

Replace an original object and do some side effects

Advantage: allow user to work with the proxy just like the original object but it can trigger side effects behind the scene.

Proxy are also used when there is a large object that would be expensive to duplicate in memory.

Behavioral

Iterator

Traverse through a collection of objects.

A pull based system.

An object with a next() method in javascript that returns a { done: boolean; value: T }.

Observer

Allow many objects to subscribe to events that are broadcast by another object.

A Subject where other objects subscribe to it and triggers their method when the subject notify

Mediator

In case of many to many relationships, one object is a coordinator between them.

Middlewares are an example of mediator.

State

What is the difference between state and strategy pattern?

This is the critical mental-model shift. CSS properties on their own are meaningless. It's up to the layout algorithm to define what they do, how they're used in the calculations.

Here's an example which blew my mind: Did you know that the width property is implemented differently depending on the layout algorithm?

I didn't know 😱

Inline space under images are due to the Flow layout and its inline elements. It adds extra-space to make sure that inline elements, such as <img />, don't negatively affect the legibility of the surrounding text.

There are a lot of layout algorithms in CSS, and they all have their own quirks and hidden mechanisms. When we focus on CSS properties, we're only seeing the tip of the iceberg. We never learn about really important concepts like stacking contexts or containing blocks or cascade origins!

Our intuition is the best tool we have. And when we start using CSS snippets without truly understanding them, it's only a matter of time until some hidden aspect of the layout algorithm throws a wrench into our gears, stopping us in our tracks.

Useful resources. I will check it out.

.full-width {
  width: 100vw;
  margin-left: 50%;
  transform: translate3d(-50%, 0, 0);
}

Or a responsive approach with CSS grid:

.wrapper {
  display: grid;
  grid-template-columns:
    [full-start] 1fr [wrapper-start]
    minmax(0, 70rem) [wrapper-end] 1fr [full-end];

  /* Optional gap */
  column-gap: var(--pad, 1rem);
}

Then

.wrapper > * {
  grid-column: wrapper;
}

.wrapper > .full-width {
  grid-column: full;
}

Build a responsive email framework with MJML and its component and templates.

Use mdx and customize its parser to generate MJML output instead of raw HTML.

Use an Email Service Provider to send email

Built with Rust and use the deno runtime.

Chiselstrike handles everything in the backend :) Can be tested someday

Check for font-palette and @font-palette-values.

Only usable in Chrome and Safari for now :(

Generate a CSS grid easily

The way to generate types from vue 3 components.
After some hours searching about how to generate types for the vue library components, this plugin for vite solved my problem.

tabs are indeed more adaptable, and carry clearer semantics that a Braille reader understands

So tabs vs spaces: tab for accessibility?

TL;DR refers to the language selector checklist

In my experience, when asked to change a country or language, a vast majority of users will immediately head to the header of the page first, and if they can’t find it there, they’ll jump all the way to the bottom of the page and scout the footer next.

I find this rule true in my experience:

We can’t confidently infer users’ preferences without asking them first.
While polite nudging is reasonable, automatic redirects are not.

As a rule of thumb: let the user choose between language, country and currency.

For example, if you want to purchase sneakers on Adidas from Germany but deliver them to your friend in Poland, you need to be able to make sense of the Polish language when checking out.

Moneses shows two tabs in the right upper corner of the header. Users can switch between language and country, defining preferences for each separately. [...] We can allow users to customize further parts of the UI, from currency and auto-translation to units of measurement and date formatting.

Preferred customization:

• shipping location
• preferred currency
• units of measure
• time/date formatting
• time zones preferences
• level of experience

Modal windows are often dismissed. So, In the mock-up above [with a modal on the bottom right], the important content isn’t blocked by the modal.

• display most languages/countries in their local format . It avoids the assumption that the user needs to understand English.
• breaking options down by tabs, either horizontal or vertical ones
• provide users with poignant autocomplete suggestions. But Sometimes the fine-tuning of making autocomplete work for many different languages might be an effort way too underestimated and way too time-consuming.
• Use the globe or translate flags to indicate the choice of locales

On Atlassian, if the user with a different browser language preference enters the site, it suggests changing the language at the very top of the page, with a globe icon appearing there, too.