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.

• aspect-ratio
• padding-bottom depending of the aspect-ratio
• css variables, but one dimension needs to be known:

  --aspect-ratio: calc(4/3);
  --height: 30vmin;
  --width: calc(var(--height) * var(--aspect-ratio));
  height: var(--height);
  width: var(---width);

• all property: change heritance rule of all CSS properties
• currentColor : value of the element's current color property
• custom property fallback value
• counters
• interaction media queries: selector depending on the primary input mechanism — touch, stylus, mouse pointer, etc. Which is not what we have
• :where and :is pseudo-selectors:
• scroll-padding: add padding on scroll, for example for a top header :D
• isolation: isolate: create a new stacking context without relying on z-index magic numbers
• content-visibility and contain-instrinsic-size for render performance optimization

A typescript enumeration containing all http status codes

I totally agree and it felt natural to me

Memory and local storage are great for “private” state — settings, caches, history. URL parameters are good for the “public” state, so that one could bookmark or forward the stateful link.

I am already applying that, but only because I had a class about it. It is useful though to have content about it online.

Sadly does not work for casual users of Firefox at the moment (2022-06-03) as stated by caniuse.

EDIT 2024: it works now.

SQL table expressions are somewhat similar to functions in a regular programming language — they reduce the overall complexity.
You can write an unreadable sheet of code, or you can break the code into understandable individual functions and compose a program out of them.
You can build a tower of nested subqueries, or you can extract them into CTEs and reference from the main query.

There is a myth that “CTEs are slow”. It came from old versions of PostgreSQL (11 and earlier), which always materialized CTE — calculated the full result of a table expression and stored it until the end of the query.

Ok. There are some rules:

• CTE runs on every request
• CTE splits the query code into multiple chunks
• instead of subquery, always use CTE for clarity

With this it is possible to try SQLite in the browser. The whole thing runs using WASM (compiled using Emscripten) and was announced by Richard Hipp as part of the SQLite 3.39.0 beta in the SQLite forum.

What is also interesting is that to load the page, less than 1 MB of data needs to be loaded. If compression were enabled, this could probably be reduced further.

sqlite3 fiddle could make it easier to quickly try something with SQLite. Instead of downloading sqlite3 first and then trying it out locally, you just open the page and can quickly use the latest sqlite3 version.

(from https://jlelse.blog/links/2022/05/sqlite3-fiddle)

How to have temporary data:
1 - Common Table Expression (or basically a named subquery)
2 - View: works like a CTE, but you can reference it by name and not repeat the subquery every time. Views are computed on the fly, similar to CTEs.
3 - A temporary table is like a real table: it stores data on disk, and you can build indexes. But it exists only while the database connection is open.

PostgreSQL and others have materialized views, which store data on disk

When to use temporary tables ?

Temporary tables are great for experimenting when you’re just getting to know the data.

background-clip: padding-box to avoid overflow of the background if border-radius is set.

A good starting point

It seems so flat to me (i.e. all the elements are on the same grid), but I think the idea is good.

With this way of thinking:

• we remove cluttered divs
• HTML stands for content and semantic; CSS for display

Unit > Integration > E2E is still a valid pyramid for testing; but better can be found.

Static analysis > Unit + Integration > e2e

Static analysis means to check the code without running it. We already have examples with Eslint as a javascript code style fixer; Stylelint for CSS code fixing (I have to try); Sonarqube

Unit and integration tests are mixed together as:

• The definition of a unit is often “to be discussed”: If you ask a group of developers to define a unit, you will mostly get various, differing answers. As some refer to a function, class, or service — minor units — another developer will count in the complete component.
• In addition to those definition struggles, drawing a line between unit and integration can be tricky, as it’s very blurry. This struggle is real, especially for Frontend, as we often need the DOM to validate the test basis successfully.
• It’s usually possible to use the same tools and libraries to write both integration tests. So, we might be able to save resources by merging them.

There are also visual tests. We can group e2e-tests and visual tests into a UI test category. Btw the recommended open-source and fully self-hosted tool for visual testing is Visual Regression Tracker