Forem: Jesco Wuester

How to set up Tailwindcss (jit) with the new Svelte kit

Jesco Wuester — Wed, 07 Apr 2021 12:18:15 +0000

Svelte kit and the new Tailwindcss just-in-time compiler just got released. Here's a super quick rundown on how to set them up (updated for tailwind 2.1 on the 8/4/2021):

Remember: Svelte config files need to use the cjs extension instead of js

Step 1: Set up the project

mkdir my-app
cd my-app
npm init svelte@next
npm install -D tailwindcss autoprefixer

Step 2: postcss

Create a postcss.config.cjs file. Svelte 3 is bundled by Vite which comes with postcss support out of the box.

module.exports = {
  plugins: {
    autoprefixer: {},
    tailwindcss: {},
  },
}

Step 3: tailwind config

Create a tailwind.config.cjs file to enable the just-in-time compiler and add the correct paths to be purged. You can also run npx tailwind init

module.exports = {
  mode: 'jit',
  purge: ['./src/**/*.svelte'],
}

Step 4: create and import the css file

Add these taggs somewhere in your css so that postcss knows where to insert the tailwind styles. A good place to import these is the $layout.svelte file.

@tailwind base;
@tailwind components;
@tailwind utilities;

And there you go. If you have any issues you can check out the finished example on github or shoot me a dm on twitter.

How to build bulletproof react components

Jesco Wuester — Sun, 12 Apr 2020 11:08:45 +0000

Introduction

React is a declarative framework. This means instead of describing what you need to change to get to the next state (which would be imperative), you just describe what the dom looks like for each possible state and let react figure out how to transition between the states.

Shifting from an imperative to a declarative mindset is quite hard and often times when I spot bugs or inefficiencies in code it's because the user is still stuck in an imperative mindset.
In this blog post I' ll try to dive deep into the declarative mindset and how you can use it to build unbreakable components.

Imperative vs Declarative:

check out this example:

Every time you click the button the value toggles between true and false. If we were to write this in an imperative way it would look like this:

toggle.addEventListener("click", () => {
  toggleState = !toggleState;
  // I have to manually update the dom 
  toggle.innerText = `toggle is ${toggleState}`;
});

Full example here

And here is the same thing written in declarative code:

  const [toggle, setToggle] = useState(false);
  // notice how I never explicitely have to update anything in the dom
  return (
    <button onClick={() => setToggle(!toggle)}>
      toggle is {toggle.toString()}
    </button>
  );

full example here

Every time you want to change the isToggled value in the first example you have to remember to update the dom as well, which quickly leads to bugs. In React, your code "just works".

The Mindset

The core of your new mindset should be this quote:

Your view should be expressed as a pure function of your application state.

or,

view = f(application_state)

or,

your data goes through a function and your view comes out the other end

React's function components align much closer to this mental model than their old class components.

This is a bit abstract so let's apply it to our toggle component from above:

the "toggle is" button should be expressed as a pure function of the isToggled variable.

button = f(isToggled)

(I'll stick to the mathematical notation from now on but they're basically interchangeable)

Let's extend this example. Say whenever isToggled is true I want the button to be green, otherwise, it should be red.

A common beginner mistake would be to write something like this:

const [isToggled, setIsToggled] = useState(false);
const [color, setColor] = useState('green');

function handleClick(){
  setIsToggled(!toggle)
  setColor(toggle ? 'green' : 'red')
}

  return (
    <button style={{color}} onClick={handleClick}>
      toggle is {isToggled.toString()}
    </button>
  );

If we write this in our mathematical notation we get

button = f(isToggled, color)

right now our application_state is made out of isToggled and color, but if we look closely we can see that color can be expressed as a function of isToggled

color = f(isToggled)

or as actual code

const color = isToggled ? 'green' : 'red'

This type of variable is often referred to as derived state (since color was "derived" from isToggled)

In the end this means our component still looks like this:

button = f(isToggled)

How to take advantage of this in the real world

In the example above it was quite easy to spot the duplicate state, even without writing it out in our mathematical notation, but as our apps grow more and more complex, it gets harder to keep track of all your application state and duplicates start popping up.
A common symptom of this is a lot of rerenders and stale values.

Whenever you see a complex piece of logic, take a few seconds to think about all the possible pieces of state you have.

dropdown = f(selectedValue, arrowDirection, isOpen, options, placeholder)

then you can quickly sort out unnecessary state

arrowDirection = f(isOpen) -> arrowDirection can be derived

You can also sort what state will be in the component and what will come in as props. isOpen for example usually doesn't need to be accessed from the outside of a dropdown.
From that we can tell that our component's api is probably going to look like this: <dropdown options={[item1, item2]} selectedValue={null} placeholder='Favorite food' />.

Writing the component now will be incredibly easy since you already know exactly how it's going to be structured. All you need to do now figure out is how to render your state to the dom.

One more example

This looks like a lot of state at first glance, but if we look closely we can see that most of them can be derived:

isDisabled = f(selectedValue, range)
"..." position = f(selectedValue, range)
middle fields = f(selectedValue, range)
amount of fields = f(selectedValue, range)

So what remains, in the end, is just

pagination = f(selectedValue, range)

here's my implementation:

It's robust, fast and relatively easy to read.

Let's take it one step further and change the route to /${pageNumber} whenever the pagination updates.

Your answer may look somewhat like this:

const history = useHistory();
const [page, setPage] = useState(1);

function handleChange(newPage){
  setPage(newPage)
   history.push(`/${newPage}`);
}

useEffect(()=>{
  setPage(history.location.pathname.replace("/", ""))
},[])

  return (
    <div className="App">
      <Pagination value={page} range={12} onChange={handleChange} />
    </div>
  );

If it does, then I have some bad news: you have duplicate state.

pageNumber = f(window.href)

pageNumber doesn't need its own state, instead, the state is stored in the url. here is an implementation of that.

Other implications

Another big implication of our new mindset is that you should stop thinking in lifecycles.
Since your component is just a function that takes in some state and returns a view it doesn't matter when, where and how your component is called, mounted or updated. Given the same input, it should always return the same output. This is what it means for a component to be pure.
That's one of the reasons why hooks only have useEffect instead of componentDidMount / componentDidUpdate.

Your side effects should also always follow this data flow. Say you want to update your database every time your user changes the page, you could do something like this:

 function handleChange(newPage) {
    history.push(`/${newPage}`);
    updateDatabase(newPage)
  }

but really you don't want to update your database whenever the user clicks, you want to update your database whenever the value changes.

useEffect(()=>{
  updateDatabase(newPage)
})

Just like your view, your side effects should also be a function of your state.

Going even deeper

There are a couple of exceptions to this rule in react right now, a significant one is data fetching. Think about how we usually fetch data:

const [data, setData] = useState(null)
const [isLoading, setIsLoading] = useState(false)

useEffect(()=>{
 setIsLoading(true)

  fetch(something)
   .then(res => res.json())
   .then(res => {
     setData(res)
     setIsLoading(false)
    })
},[])

return <div>{data ? <DataComponent data={data} /> : 'loading...'}</div>

There is a ton of duplicate state here, both isLoading and data just depend on whether our fetch promise has been resolved.
We need to do it this way right now because React can't resolve promises yet.

Svelte solves it like this:

{#await promise}
    <!-- promise is pending -->
    <p>waiting for the promise to resolve...</p>
{:then value}
    <!-- promise was fulfilled -->
    <p>The value is {value}</p>
{:catch error}
    <!-- promise was rejected -->
    <p>Something went wrong: {error.message}</p>
{/await}

React is working on something similar with suspense for data fetching

Another big point is animation. Right now, updating state at 60fps is often not possible. A great library that solves that in a declarative way is react spring. Svelte again has a native solution for this and I wouldn't be surprised if that's something else react will look at in the future.

Final thoughts

whenever

your app rerenders often for no real reason
you have to manually keep things in sync
you have issues with stale values
you don't know how to structure complex logic

take a step back, look at your code and repeat in your head:

Your view should be expressed as a pure function of your application state.

Thanks for reading ❤

If you didn't have that "aha-moment" yet I recommend building out the pagination or any component that you can think of and follow exactly the steps outlined above.

If you want to dive deeper into the topic I recommend these 2 posts:

If you think there is something I could make clearer or have any questions/remarks feel free to tweet at me or just leave a comment here.

Webpack, babel and the "Modern Webapp" explained

Jesco Wuester — Thu, 23 Jan 2020 07:46:51 +0000

Webpack and Babel weirded me out for a long time. Luckily Create-react-app always took care of all of that stuff for me so I never had to peek into what it does. Turns out it's not all that complicated and learning it is a crucial step if you want to become a better developer.

Webpack?

Webpack is a module bundler.
Great, but what does that mean?

To understand that we have to go through a bit of history:
In the dark ages javascript was used like this:

<script>
alert('stay on this page to win 1000000$ !!!1!')
</script>

Javascript was mostly used for small scripts and popups so you didn't need a lot of code. As the web matured and apps became more complex writing all your code in just one js file became unmaintainable due to the sheer length of the files but also because naming collisions became unavoidable. Some hacky solutions like IFFEEs tried to solve the problem, but they all had vital flaws, IFFEEs were notoriously slow for example. Finally, Webpack was born.
In oversimplified terms, Webpack takes all your javascript files and creates one huge javascript file out of them that you can then include in your HTML page. This huge file is called the bundle (and often named bundle.js.
To do that it renames all variables (or namespaces them). This also includes the javascript files from you node_modules folder!
So instead of index.js, button.js and node_modules/some_package/index.js you only get 1 bundle.js file that includes the code from all of them.

Webpack now also has a ton of custom loaders to include not just js files but also fonts, CSS files, images and pretty much anything else you could imagine. (A custom loader is just a file that tells webpack how to include something like an image in your bundle). It also automatically removes all variables that you don't use from your bundle (this is called threeshaking) and does a ton of other cool stuff to make your bundle smaller (since every user of your website has to download your bundle before being able to use it a smaller bundle means faster page load).

You can read more about the history of webpack here

Babel

Babel is a JavaScript compiler.
Is that different from a module bundler?

Yes! Babel was born out of a need for backwards compatibility. Your websites probably need to support old browsers, sometimes as old as IE9.
But you still want to use new javascript features (like let, const, class or .then(). Babel takes your code and rewrites it as backwards-compatible code (compiles it). So const myName = 'tim' becomes var myName = 'tim'. Babel makes sure that everything still works as intended, so for example when you try to reassign myName it creates an error (since const can't be reassigned).

Play around with it here

It can also transform syntax like react's jsx

The Modern Setup

The modern web development setup now takes care in 2 places:

Compilation and Bundling (which happens in NodeJs on your computer)
Execution (Which usually happens in the user's browser)

Where to go next

If you're interested in getting to know any of these topics deeper I recommend doing any of the following:

Set up a complete react setup (with babel and jsx) using only the webpack and babel docs
Learn about all the different module systems used today (cjs, es6 import, amd)
Learn about AST's and write your own babel plugin (I swear its easier than it sounds)

Hope this post helped clear some things up. If you have any feedback on this blogpost leave a comment down below, I really appreciate it!

What are some real-world scenarios where redux is needed?

Jesco Wuester — Wed, 18 Dec 2019 12:38:40 +0000

I'm struggling to see how redux is helpful. In pretty much every case state should be controlled by its own component and not made global (like redux does). There may be some exceptions like a user or shopping cart object or sth like that, but those can be solved with just one context provider.
Has anyone worked on a codebase (or does anyone know of an example) that really needs redux?

What eslint config do you use with react

Jesco Wuester — Wed, 11 Dec 2019 14:11:41 +0000

I used to use eslint-plugin-react but found more and more nonsense rules in there like https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-props-no-spreading.md. I only want to see an error when there's an actual bug or bad practice (like unused variables, same variable name in upper scope, forgot to close a bracket etc). No styling stuff (I have prettier for that)

A comprehensive guide to responsive Images (picture, srcset, source etc)

Jesco Wuester — Mon, 18 Nov 2019 14:57:37 +0000

The specifications for responsive images went through years of debate and many iterations + it's a pretty wide area to cover so the syntax is a bit over the place. In this article, I'll try to give you a full understanding of all the different methods for creating responsive images.
I'll break it down into 3 parts:

Why you should use responsive images
A syntax breakdown
My recommended setup for responsive images

Why

As discussed in the first part of this series, big images can make your site incredibly slow. We already cut down the file size by compressing our images, but on phones, you still get the same image resolution as on desktop. Responsive images allow you to serve different resolutions depending on either screen size, screen resolution or image width.

Syntax

There is a multitude of ways to make your image responsive, to understand how they work we have to break down a bit of new syntax:

src
srcset
picture
source

Let's start with an example and go over what all the pieces of syntax do.

<img src="file-200px.jpg"
     alt="some file"
     srcset="file-200px.jpg 1x, 
             file-400px.jpg 2x, 
             file-600px.jpg 3x>

src

src="file-200px.jpg"

This determines the source of the image. It's also used as the source on all browsers that don't support srcset.

srcset

     srcset="file-200px.jpg 1x, 
             file-400px.jpg 2x, 
             file-600px.jpg 3x

Srcset is made up of one or more image candidates. The candidates are separated by a comma and each candidate contains an image URL and an optional condition. If the condition is fulfilled the candidate source will be used instead of the default source.

the conditions

1x, 2x etc (display density)

With the introduction of high density screens CSS had to make a distinction between a pixel as a measurement unit and an actual pixel on a screen so that the layout wouldn't look tiny on high-resolution screens.
On the iPhone 11, for example, every CSS pixel is actually 2 device pixels big. This means the device pixel ratio is 2x.

     srcset="file-200px.jpg 1x, 
             file-400px.jpg 2x, 
             file-600px.jpg 3x"

So what our example does is it serves users with a high-density screen a higher resolution image so that they can take full advantage of their high resolution. At the same time, we make sure that users with a lower density screen don't have to waste unnecessary data.

Translated into words the syntax above means

if the user has a device pixel ratio of 1x, serve him file-200px.jpg
if the user has a device pixel ratio of 2x, serve him file-400px.jpg
etc

200w, 400w etc (width descriptors)

     srcset="file-200px.jpg 200w, 
             file-400px.jpg 400w, 
             file-600px.jpg 600w"

The width descriptor describes the resolution of your file. So the actual width in pixels when you open your image in a photo editor or so. The browser will use that width to decide what image source to use. Unfortunately, just the image resolution isn't enough information for the browser to make a decision.
When the browser begins downloading its assets it doesn't know the width of the slot that the image element will eventually fill in the page, so to use width descriptors we have to tell the browser what size our image will have! Width descriptors can't be used without the sizes attribute, so the whole syntax actually looks like this:

     srcset="file-200px.jpg 200w, 
             file-400px.jpg 400w, 
             file-600px.jpg 600w"
     sizes="(min-width: 900px) 700px,
            (min-width: 400px) 80vw,
            100vw"

This syntax can be intimidating at first but is actually fairly straight forward, all we do by specifying the sizes is tell the browser:

"when the screen is more than 900px wide, the width of the slot the image will fill is 700px.
"when the screen is more than 400px wide the width of the slot the image will fill is 80vw.
"when none of the media conditions are true the width of the slot the image will fill is 100vw"

You can use absolute units (like px or em) or a length relative to the viewport (vw) but not percentages.

The browser is going to use these sizes to:

Look at its device width
Work out which media condition in the sizes list is the first one to be true
Look at the slot size given to that media query
Load the image referenced in the srcset list that most closely matches the chosen slot size

The picture tag

The syntax above can be really hard to keep track off if not properly formatted and is still a bit limited. Luckily there's an alternative.

<picture>
    <source srcset="example-200px.jpg" media="(min-width: 800px)">
    <source srcset="example.webp" type="image/webp">
    <img src="example.jpg" />
</picture>

The picture tag takes in one img element and zero or more source tags. A good way to think about it is that the picture element supercharges the img element in it with the different sources. Browsers that don't support the picture or source tag will simply ignore it and just render the img element in it.

The source tag

You may have already seen the source tag inside of a video tag or so. Inside of the picture tag it can be used to accomplish a variety of things:

use modern image formats

In the example above we use <source srcset="example.webp" type="image/webp">. Webp is a modern image format that I talked about in the first part of this series. Since browser support for it is still a bit spotty we can't use webp as our only src for an image but with the source tag we can specify a webp source and all browsers that support webp will use it. Be sure to specify the type as image/webp so that the browser can read it.

change the src depending on viewport size

<picture>
  <source media="(max-width: 800px)" srcset="example-small.jpg">
  <source media="(max-width: 1200px)" srcset="example-large.jpg">
  <img src="example-default.jpg">
</picture>

This syntax is pretty self-explanatory when the viewport size is smaller than 800px it will display a smaller version of the image. Instead of supplying a lower resolution version of your image you can also supply a completely different image on smaller screens. This can be really useful if you want to show for example a less detailed, or more zoomed-in version of an image on smaller screens.

use srcset and size

  <source srcset="file-200px.jpg 200w, 
             file-400px.jpg 400w, 
             file-600px.jpg 600w">

a source can also support a srcset and sizes tag, just like the regular img tag.

How

Your approach should always depend on your use case. I would always use a picture tag since it lets you use webp and is the most flexible. When working with a framework like vue, react, svelte etc I recommend making a reusable component that integrates with your backend setup. For example in react it could be something like this:

<MyPictureComponent
     sizes={{
         default: allSources.medium,
         mobile: allSources.small,
         desktop: allSources.large
     }} 
/>

which would render sth like this:

<picture>
  <source media="(max-width: 800px)" srcset={sizes.small.webp} type="image/webp" />
  <source media="(max-width: 1200px)" srcset={sizes.large.webp} type="image/webp" />
  <source media="(max-width: 800px)" srcset={sizes.small.jpg} />
  <source media="(max-width: 1200px)" srcset={sizes.large.jpg} />
  <img src={sizes.default.jpg} />
</picture>

That way webp is handled by default and the whole thing is a bit less verbose.

Do you have a nice abstraction for responsive images? Let me know 👇

summary

the srcset attribute allows you to supercharge your img tag by providing it with a list of alternative sources and conditions.
conditions can be based on the screen density and image size.
the picture tag allows you to specify a bunch of sources for an image to specify different images at different screen sizes and use modern image formats with a fallback.

Understanding Image formats on the Web

Jesco Wuester — Thu, 14 Nov 2019 17:44:29 +0000

Images are probably the #1 performance bottleneck on websites. Tons of developers spend hours shaving of some kb of their bundle while serving megabytes worth of images.

Image Optimization consists of 3 main parts:

Using the right image format(s)
Using responsive images (will be release 18.11)
Using Progressive/Lazy image loading (will be release 25.11)

In this series, I'll go over each off these topics so that hopefully by the end you'll have a full understanding of how images on the web work. This first part covers what format you should use for your images.

Using the right image format(s)

There's 4 main formats you should know:

jpg
png
svg
webp

Let's go through each of them

JPG (or jpeg, its the same)

Probably the most common image format, jpg's are small and can display a wide range of colours so they're well suited for photos. Due to the way JPGs are compressed (which is called "lossy compression") they're pretty bad at showing sharp edges (like between the white and the black in the image below), so they're not well suited for logos and illustrations.

There's also JPEG2000 and JPEG XR which were created after the original jpg spec to improve on it, but browser support is so slim that you shouldn't use them on the web.

PNG

PNGs use "lossless compression" which makes them much better suited to show sharp edges. They also support opacity. The drawback is that the file size is larger than that of a JPG. You can use PNGs for illustrations and logos but there is often a better option:

SVG

SVG stands for "scalable vector graphic". SVGs look a bit like HTML which makes them incredibly small and versatile. SVGs can be edited with CSS and animated in a lot of different ways. They can also be scaled to any size since they're not encoded in pixels (see example down below). If you have the option it's usually best to use SVG for Icons, Logos etc, but often times (especially when dealing with illustrations) you will be stuck with a PNG and you can't reliably convert a png to an svg.

This is what an svg looks like

<svg width="12" height="12" viewBox="0 0 12 12" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M6 11.377C6.22266 11.377 6.48633 11.2715 6.73242 11.1133C9.92578 9.0625 11.9238 6.60156 11.9238 4.16992C11.9238 1.96094 10.4473 0.460938 8.53125 0.460938C7.5 0.460938 6.63281 0.953125 6 2.00781C5.36719 0.947266 4.49414 0.460938 3.46289 0.460938C1.54688 0.460938 0.0703125 1.96094 0.0703125 4.16992C0.0703125 6.60156 2.07422 9.0625 5.26172 11.1133C5.50781 11.2715 5.77148 11.377 6 11.377Z" fill="currentColor"/>
</svg>

It's a heart :D

WEBP

WEBP was created by Google in 2010 as an image format for the web. It supports both lossless and lossy compression, supports opacity and is usually smaller than both png and jpg. It's pretty amazing and has decent browser support (80% at the time of writing). WEBP should always be used with a fallback option to cover that remaining 20% (you'll learn how to do that in the next part). It will have a huge positive impact on your site though and support is only expected to grow.

How do you compress

If you want to compress just a few static images use https://squoosh.app/. It also lets you play around with different types of compression and see the difference in quality and filesize in real-time!
If you need to compress a lot of images/dynamic images you can use something like sharp on your backend to compress your image to multiple versions.
Alternatively, there are also services like Cloudinary that compress images for you and distribute them over a CDN (which is also usually faster than your server)

Summary

Use SVG for logos/icons etc or anything you want to animate
Use WEBP for everything else with either JPG or PNG as a fallback
Use JPEG for Photos (as a fallback for webp)
Use PNG for logos/illustrations etc when no SVG is available (as a fallback for webp)