DEV Community: Ilia Mikhailov

Tailwind CSS and SvelteKit - The Easy Way

Ilia Mikhailov — Tue, 26 Oct 2021 00:00:00 +0000

Long story short, I needed to integrate Tailwind CSS into a new SvelteKit project and searched around on the Internet on how to do it. The first option is to use svelte-add, but it won't work unless you start off with a fresh project. The other common way to do it is some variation of my old Sapper and Tailwind solution. While it's still valid today turns out there is a much simpler way to do it.

This post was originally published at codechips.me

Create new SvelteKit project

When you create a new SvelteKit project with npm init svelte@next my-app command you have a few options to choose from. The choices you make will affect how easy it will be to integrate Tailwind CSS. For example, here are the choices that I made during my project creation.

As you can see in the screenshot above I chose TypeScript support. In order to get TypeScript working in Svelte you have to use svelte-preprocess library. That library is also the key to get Tailwind working in our project. Its job is to support and process many different languages in Svelte templates and it also has built-in support for PostCSS that Tailwind is based on.

Don't worry if you didn't choose TypeScript as an option in your project. You can install svelte-preprocess separately and implement it in your svelte.config.js like this.

// svelte.config.js

import preprocess from 'svelte-preprocess';

/** @type {import('@sveltejs/kit').Config} */
const config = {
  // Consult https://github.com/sveltejs/svelte-preprocess
  // for more information about preprocessors
  preprocess: preprocess(),

  kit: {
    // hydrate the <div id="svelte"> element in src/app.html
    target: '#svelte'
  }
};

export default config;

Now that we have PostCSS support in place let's move on and install and configure Tailwind CSS and other required libraries.

Install Tailwind CSS and friends

First things first, we need to install Tailwind and supporting NPM packages and Tailwind configuration file.

$ npm add -D tailwindcss autoprefixer postcss-load-config
$ npx tailwindcss init

For this to work we also need to create PostCSS configuration in our project directory.

// postcss.config.js

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

We are almost ready to go, but if you start you project you will get an exception that has the following error message in it somewhere.

Instead rename tailwind.config.js to end in .cjs, 
change the requiring code to use import(), 
or remove "type" : "module" from [...]/package.json.

What Node basically says is that it expects a different type of module. The solution is simple. Change extensions for Tailwind and PostCSS configs from .js to .cjs.

In order for Tailwind to know what CSS it needs to purge during production builds you have to add purge patterns to your Tailwind config.

// tailwind.config.cjs

module.exports = {
  // add this section
  purge: [
    './src/**/*.html',
    './src/**/*.svelte'
  ],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

We now have a correct Tailwind and PostCSS setup in place. Let's use it.

Import your CSS

The last step is to create a Tailwind CSS file and import it in the project. Create an app.css file under src directory, if it's not there already, and add the following to it.

/* app.css */

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

@layer base {
  h1, h2, h3, h4 {
    @apply font-bold;
  }
}

Next step is to require that file in your template. Here I added it to my main layout file.

// __layout.svelte

<script lang="ts">
  import '../app.css';

  import Header from '$lib/components/Header.svelte';
  import Login from '$lib/components/Login.svelte';
  import { auth } from '$lib/auth';
</script>

<main>
  <Header name={$auth.company?.name} />
  <div class="max-w-4xl mx-auto py-8">
    {#if $auth.loading}
      <div class="text-gray-600">Loading ...</div>
    {:else if $auth.user}
      <slot />
    {:else}
      <Login />
    {/if}
  </div>
</main>

If you start the application now the Tailwind CSS should kick in.

<style lang="postcss">
  .content {
    @apply text-lg text-gray-600;
  }
</style>

You can also use Tailwind directives in your style tags. I usually add lang="postcss" to get rid of editor warnings, but you can safely omit it if you want as it has no effect on the functionality.

That's all there is to it. Tailwind CSS integration in SvelteKit in 3 easy steps. If I now counted correctly that is.

Sneaky painful frontend burnout

Ilia Mikhailov — Tue, 28 Sep 2021 00:00:00 +0000

I've recently noticed an alarming trend. There is a high churn of frontend developers due to the burnout. It's a shame, but it totally makes sense if you take a deeper look at the problem. It's not something you normally notice. All burnouts are sneaky, but this one is special. It comes creeping very slowly and before you notice it's too late. This article is a personal reflection from the interviews conducted with people who decided to leave the frontend field due to the burnout.

Originally published on codechips.me

Rough history of web development

Things were simpler back in the days. jQuery was king and we relied on it to get things done. And we did get things done too. Browser wars made the frontend world accelerate at incredible speed. There were many new cool APIs we could use, but they were often browser specific. This created a lot of inconsistencies and forced us to use polyfills. Modernizr was a popular library that we relied on to detect what was possible for us to do in the browser.

The speed of browser advancements propelled the development of new tools. Bower was a popular, but short-lived package manager for the web that many developers relied on. We used different task runners such as Grunt and Gulp to get things done. The frontend ecosystem was getting complex, but we could still wrap our heads around it.

We were getting things done with the tools and libraries we had, but it wasn't enough. We wanted more and better tools. Webpack was gaining traction and Browserify was released and this is where I personally lost track of everything. I think it was around 2014 where things got blurry and made it impossible to keep track of all the news. This is also the year when I had my first frontend burnout and decided to move back to backend development. It became too much. I craved simplicity.

Let's fast forward to today and see if things have improved. The popular frameworks of the past are merely ghosts of their former glory. Today, React is the undisputed king followed by many other modern frameworks such as Svelte, Vue and Angular. TypeScript has become a de-facto standard language of web development. For sure, frameworks and languages have advanced for the better, but did they actually make our life simpler or allowed us to reduce time to market?

npm install broke the Internet

My opinion is that npm install broke the Internet. There were a few different attempts to bring package management to Node.js and NPM won. Today it's the standard of JS package management, but in the beginning it was actually for managing packages for Node.js only, hence the name - N ode P ackage M anager.

Not that long after developers realized that they could also publish frontend libraries to NPM. I think it was Bower package manager that started the trend. Sometimes later, Bower quickly became out of fashion when most of developers switched to different JS bundlers. Fast forward to today and think of one frontend project that doesn't use a bundler and downloads half of the Internet when you run npm install.

That's the norm today. Why is it like this? First, NPM's recommendation to package creation was to create small focused packages that do one thing and do it well and I was a big proponent of this myself telling all other developers to think this way. Second, it's often easier to find and install a package from NPM than to write it yourself. Is it a good thing? I am not sure. Remember the leftpad incident? Also, if you rely on some NPM package and find a bug in it, how much effort is required to fix it versus if you would have written the functionality yourself?

It's easy to add new packages to your project and if it's easy we tend to do it. We have too much freedom of choice. It's also a little too easy to publish packages on the NPM and everyone wants to scratch their own itch. I am not saying it's bad. On the contrary, sharing knowledge and contributing to open source is good, but does it really justify itself as NPM package? Maybe a simple Github gist is enough? Copy, paste, adjust.

Here is a thought experiment. Would you be able to build the same app with the same level of interactivity if you could only add your dependencies as scripts in the document head? How cautious would you be?

Enter TypeScript

JavaScript is a cool language that mixes OOP with FP. Pick and choose. It's also a messy language. Actually not messy, but maybe the right word would be - flexible, and if you know your way around the language and all its quirks you will do just fine. Many existing websites and apps were written using plain JS.

When TypeScript entered the scene (almost) everyone cheered and thought that it will make all of their JS problems go away. Sure, it might have solved some of the existing problems, better IDE autocomplete comes to mind, but what people don't realize is that by adopting TypeScript they just made their developer lives more complex. If you ask me, TypeScript is a weird language with a fake type system that gives you fake confidence. I too do use TypeScript for some projects, but it feels like the only thing I do is try to keep the TypeScript compiler happy.

TypeScript is rarely frictionless, especially its setup. I bet there are very few developers that throw together a working tsconfig.json on the first try. It comes with a cost and it's something you have to think about. Because it's so wide-spread today, it's hard not to use TypeScript when building open source libraries. I mean, you don't want people to think you are a weirdo, right?

Adopting TypeScript is not enough. There is a whole JS surrounding ecosystem that you have to adopt to as well. Because JS is such a loose language you have to solve linting and code formatting. Should you adopt ESlint or StandardJS? Is there room for Prettier? If you go with ESlint what plugins do you need? Should you adopt Airbnb style or is there something else, something better and newer? You might want to introduce automatic linting too so you can't commit bad code. Husky might help you with it.

The tooling ecosystem surrounding JS adds additional complexity layer to your project. Now, I am sure that you can reach the perfect setup for your project, but how many many hours of frustration, searching and reading documentation did it take you to get there?

Where are we at?

It's clear that the frontend world is getting more and more complex and those people who tell you it's still young and we are still trying to find good solutions to existing problems are ignorant. Two decades is a long time for the dust to settle, but if you keep adding more wind all the time your sight of view will only get shorter. The wind is added by a lot of new frameworks and libraries, the flexibility and shortness of the JavaScript as a language and NPM. It's too easy to publish and consume NPM packages today and everyone is doing it. The flexibility and the possibility is what got us here. I understand that innovation is hard, it's blood, sweat and tears, but what if we have been running in the wrong direction this whole time? The direction of complexity instead of simplicity.

In fact it's so bad that I've heard that some of the developers have developed the green field project anxiety. There are too many choices and they rather take on maintenance projects than make the tough decisions. React fatigue and overall frontend fatigue is real. How do I know that the tech stack I am betting on will still be relevant in two years? SSR or SPA, routing, state management, style libraries. It's easy to end up in the state of analysis paralysis and it's not a nice place to be in.

We also tend to get things backwards. Developers think that in order to get things done you have to use [insert some cool framework name here]. I've witnessed this myself. I have seen code schools teaching newbies without any IT experience how to build apps with React without teaching them the basics of HTML and how the web works. That's crazy, but also sad. It's sad how much money people pay in hope to get a job after they finish the coding course.

It's not the fault of the people who taught the course. It's Economics 101, demand vs supply. If someone can make money out of you they will. React should be the last thing you learn because React is super-complex, but there is a surge for React developers so let's skip the essentials and concentrate on the needs of the market.

Choosing boring technology for the project is boring. I myself is guilty of this too. Luckily I can figure most of the things out because I have a lot of experience under my belt, but it can imagine how frustrating it can be for a newbie. Heck, sometimes even I don't figure stuff out. Not because I can't, but because it's hard and I don't want to invest my time in it, spend my mental energy. To me it's a clear sign of how complex current frontend stack is.

This leads me into the main topic of the article - the dreaded frontend burnout.

The signs of burnout

This burnout type is sneaky. You don't usually notice it because it doesn't really feel as a burnout, but more like a never-ending mild frustration at first.

It's a slow burnout. It's like drinking coffee from your favorite coffee cup that has a small, but sharp crack in it just at the right place and you scratch your lip every time you take a sip. First it's annoying, but then you get used to it, only to realize months later that you have had enough, and you throw that cup into the wall with anger.

When you reach this moment it's usually too late. That's why you have to pay close attention to the following signs.

Bringing your work home. Not physically, but mentally. If you come home with the constant nagging feeling that you didn't finish what you planned to accomplish today. The feeling of mild frustration.

Yak shaving. If you feel that the only thing you do is fight with the tools and project related things and it leads to a lot of time spent tweaking, solving, dependency management, but no actual coding. Frustration builds up.

Mentally taxing. If you come home mentally drained and the only thing you have energy left to do is to watch Netflix. You have no power to do anything else.

Lost opportunity cost. If you start doubting if building UIs and web sites was the right career choice for you. You ask yourself if things would be different if you programmed an operating system or backend APIs, but you are building interactive UIs and it's just as complex.

Negative feedback loop. If you feel that things are getting worse at work every day and you are not getting anything done.

Work/life balance. If you feel that work bleeds into your private life and work/life boundaries become fuzzy. It can be as simple as thinking about the unfinished ticket in the evening or fail to fall asleep because you are thinking about work. This is especially common if you work remotely.

Performance drop. If you feel tired and lethargic when you come to work and can't get anything done. You have hard time concentrating on the task at hand and procrastinate. Nothing feels exciting anymore.

Framework envy. If you are thinking that things would be easier, more productive or fun if only you used another framework or technology in the project.

Quitting. If you are thinking about switching jobs. This is a common fallacy. People often think it's their current employer that is the problem, but oftentimes it's not.

Denial. If people close to you tell that you have changed lately or you are not present mentally, and you blame it on the tough intense period at work, it's definitely a sign. It's called self-denial.

These are just a few signs that you are nearing the point of no return and it's only a matter of time before the burnout hits you. There are also always physical symptoms associated with those feelings. The most common are: lack of energy, irritation, agitation and sleeping trouble. Pay close attention to your body, not only to your mind.

If you can relate to any of those signs it can mean that you've caught this early and it might not be too late yet. Recognizing and accepting is the first and most important step.

My best advise here would be to take a break and go out for long walks in the nature. They help clear your mind plus you get the physical exercise as a bonus. Also, make sure to book some social events with friends or family even if you feel that you have to force yourself. Next step is have an honest talk with your manager and explain how you feel. It might be hard to do, but you will be glad you did it.

What can we do?

There are things in my opinion we can do to reverse this trend, and they are exciting too, but it's a topic for another upcoming article.

Tune in into your feelings

I fully understand, and accept, that the frontend world is turbulent at the moment, and it will be a bumpy ride before we get to somewhat stable state, but please be careful. Watch out for the signals yourself, watch your friends and colleagues. Pay close attention to how you feel and your body. Burnout is never worth it.

Think objectively. Development is fun, but sometimes it can be too fun. Do you really need to use this frontend framework? Do you really need to use SSR? Is SEO a requirement? Remember that complexity increases with every choice you make. It might not be obvious at first when you get everything setup and running, but it will be obvious later when you find yourself in the hole you that have been digging yourself and it's too deep to climb up from.

We, as programmers, often tend to complicate things. It's in our DNA. We like a good challenge, to solve complex problems and we are really good at it too. The problem is that the complexity often steals our time. Time that is better spend building features instead that bring real value to the users.

Next time you are about to start a new project always ask yourself: What is the simplest solution I can get away with?

It's totally fine if you don't agree with me on everything. I just wanted to get it off my chest.

How to setup Vim for Svelte development

Ilia Mikhailov — Thu, 10 Dec 2020 00:00:00 +0000

I like Vim. I like its simplicity, its ugliness. There is something appealing about its GUI constraints too.

Let's be honest. Trend sensitivity in tech is a big problem. Developers are jumping from editor to editor whenever something new, hot and trendy comes out. Always searching for the Holy Grail. Sublime, Atom, VSCode. What comes next?

Vim is a very old editor. It's 25 years old. That's ancient in the tech world. What can possibly justify this piece of software's existence? Something must be good if it still lives, right? What are the benefits?

One of Vim's powers is its simplicity and extensibility. It's a very extensible editor. It's also scriptable. It has macros and tons of other useful features. It's small, doesn't hog your CPU and make your computer fans go crazy. It often comes prepackaged with almost every Unix-like operating system.

It's also a powerful editor for Javascript, TypesScript and Svelte development.

Neovim

Neovim is the modern fork of Vim. Its goal is to clean and extend Vim with modern features. Personally, I don't use Neovim. I tried it, but I can't honestly tell what makes it better than the original Vim. The gains are not obvious to me. I am sticking to orginal Vim for now, currently version 8.2.

Ever Heard of Emacs?

You might say "But what about Emacs?" I tried Emacs too for a while after getting inspired from watching Emacs Rocks videos. Tried only to realize that I was spending most of my working time configuring Emacs instead of doing the actual work. Also, I already have an operating system, thank you.

Oh, and you know, all those people who just have to crack a joke about exiting Vim, why don't you ask them to try and exit Emacs next time? Look who is laughing now!

Side note: Vim + Tmux = Power

I always use Tmux and Vim together. What it Tmux? I would describe it as a tiling window manager for the terminal. You have to tweak it a bit to you liking, but once you master it, windows will start flying.

This is out of scope for the article. I just wanted to mention it.

Svelte Syntax Highlighting

First things first, we have to configure Vim syntax highlighting for Svelte, Javascript and TypeScript.

For Svelte, vim-svelte is the plugin to use. It provides indentation and syntax highlighting for Svelte components. There is also vim-svelte-plugin that does the same thing.

For Javascript language highlighting, you have a few different options. The most popular seem to be vim-javascript and this is what I use.

There is also vim-js and jats. If you are feeling adventurous check out vim-polyglot, a plugin with more language syntax hightlights that you probably will ever need.

When it comes to TypeScript, I settled on yats.vim. I find it the best, but typescript-vim is another good option.

I am using vim-plug as my Vim plugin manager and if you do too, this is how to add them to Vim config file.

Plug 'evanleck/vim-svelte'
Plug 'pangloss/vim-javascript'
Plug 'HerringtonDarkholme/yats.vim'

Syntax highlighting is a nice to have, but autocomplete is essential for a good coding session. Let's tackle that next.

Svelte Autocomplete with Coc.nvim - Conquer of Completion

Honestly, how did I write code in Vim before this extension existed? Apparently I did, but I bet it was painful.

Coc.nvim is a must-have if you are a Vim user. It's an "Intellisense engine for Vim8 & Neovim, full language server protocol support as VSCode" according to their website.

What does it mean? It means it supports the same language protocol standard as VScode, which in turn means you can easily implement an autocompletion for a language if that language has a language server. Crystal clear, right?

Here is Svelte's language server for example.

Installing Coc.nvim is straight forward. Add the line below to your .vimrc in the right place and run :PlugInstall.

Plug 'neoclide/coc.nvim', {'branch': 'release'}

Coc.nvim has many extensions and we will install one for Svelte next, along with a few others we will need too.

coc-svelte

If you are coding Svelte in Vim coc-svelte is a must. Unfortunately, the original extension's Svelte dependencies are lagging behind, so I keep my own fork of it where I try to keep upstream dependencies in sync.

Add it to your .vimrc with the line below.

Plug 'codechips/coc-svelte', {'do': 'npm install'}

Beside Svelte extension we also need to install TypeScript Coc extension. It will help us with autocompletion for TypeScript and JavaScript. Install it in Vim by running :CocInstall coc-tsserver command.

Coc.nvim autoupdates dependencies in the background, but you can always update them manually by running :CocUpdate command.

Setting up svelte.config.js

If you are using TypeScript, SASS or PostCSS in your Svelte components you have to create a svelte.config.js file in the root of your project. That file is needed by coc.nvim in order to interpret those parts of the Svelte files correctly. Read my TypeScript and Svelte article on how to do that - How to use Typescript with Svelte.

Formatting Files with Prettier

We also want our files to look nice and therefore we need to format them. There is a coc-prettier extension that does that, but for some reason it breaks Svelte files for me instead. Sometimes it doubles the lines at the end of the file. For that reason I decided to go with vim-prettier extension instead.

For Prettier extension to work properly it needs to find a prettier CLI and Prettier configuration. There are multiple ways of configuring and setting it up, but I always do it locally for every of my projects. It's the easiest.

$ npm add -D prettier prettier-plugin-svelte

You also need to add Prettier vim plugin to your Vim config and tweak some of its settings.

Plug 'prettier/vim-prettier', { 'do': 'npm install' }

" Prettier Settings
let g:prettier#quickfix_enabled = 0
let g:prettier#autoformat_require_pragma = 0
au BufWritePre *.css,*.svelte,*.pcss,*.html,*.ts,*.js,*.json PrettierAsync

One drawback of Prettier is that you have to install Prettier and prettier Svelte plugin in every Svelte project. It might be possible to use a global Prettier config, because it will search for Prettier configs up the tree.

However, I strongly advice against doing it, because you might want to share same config with your team.

My prettier config usually looks something like this.

module.exports = {
  arrowParens: 'avoid',
  printWidth: 90,
  singleQuote: true,
  svelteBracketNewLine: true,
  svelteStrictMode: false,
  trailingComma: 'none',
  plugins: ['prettier-plugin-svelte'],
};

Prettier uses cosmiconfig. That means you can use any name and format it supports.

Configuring Coc.nvim

If you need to configure Coc.nvim and its extentions you can open the config file directly in Vim by running :CocConfig command. You can also edit the coc-settings.json file directly. You will find it in your ~/.vim folder or ~/.config/nvim if you are using Neovim.

Here is what mine looks like.

{
  "diagnostic.messageTarget": "echo",
  "signature.target": "echo",
  "coc.preferences.hoverTarget": "echo",
  "javascript.suggestionActions.enabled": true,
  "typescript.suggestionActions.enabled": true,
  "prettier.printWidth": 120,
  "prettier.singleQuote": true
}

All those "echo" values force Coc to display diagnostic messages in Vim's command line instead of a popup. I don't like distracting popups.

These are Coc.nvim settings in my .vimrc.

" COC
let g:coc_node_path = '$HOME/.nvm/versions/node/v12.16.3/bin/node'

nmap <leader>rn <Plug>(coc-rename)
nmap <silent> gd <Plug>(coc-definition)
nmap <silent> gy <Plug>(coc-type-definition)
nmap <silent> gi <Plug>(coc-implementation)
nmap <silent> gr <Plug>(coc-references)

set updatetime=300
set shortmess+=c " don't give |ins-completion-menu| messages.

" Use K to show documentation in preview window
nnoremap <silent> K :call <SID>show_documentation()<CR>

function! s:show_documentation()
  if (index(['vim','help'], &filetype) >= 0)
    execute 'h '.expand('<cword>')
  else
    call CocAction('doHover')
  endif
endfunction

Maybe you can get some inspiration from reading them.

A Few More Tips

It's not sure that Vim will recognize that your Svelte file consists of different sections and languages (JavaScript, CSS) and might comment them out using HTML comments when you try to comment them out.

It happened to me, and if it happens to you, here is how to solve it.

Install the context_filetype Vim plugin. It will help us set the filetype based on the file section.

Plug 'Shougo/context_filetype.vim'

Add the following code to your Vim config.

if !exists('g:context_filetype#same_filetypes')
  let g:context_filetype#filetypes = {}
endif

let g:context_filetype#filetypes.svelte =
\ [
\   {'filetype' : 'javascript', 'start' : '&lt;script&gt;', 'end' : '&lt;/script&gt;'},
\   {
\     'filetype': 'typescript',
\     'start': '&lt;script\%( [^>]*\)\? \%(ts\|lang="\%(ts\|typescript\)"\)\%( [^>]*\)\?>',
\     'end': '</script>',
\   },
\   {'filetype' : 'css', 'start' : '&lt;style \?.*>', 'end' : '&lt;/style&gt;'},
\ ]

let g:ft = ''

Now your comments should behave correctly.

I am using NERDCommenter, a Vim commenting plugin with the best punchline - "Comment functions so powerful - no comment necessary."

For it to work properly with Svelte I had to tweak its settings a bit.

" NERDCommenter settings

let g:NERDSpaceDelims = 1
let g:NERDCompactSexyComs = 1
let g:NERDCustomDelimiters = { 'html': { 'left': '<!--', 'right': '-->' } }

" Align comment delimiters to the left instead of following code indentation
let g:NERDDefaultAlign = 'left'

fu! NERDCommenter_before()
  if (&ft == 'html') || (&ft == 'svelte')
    let g:ft = &ft
    let cfts = context_filetype#get_filetypes()
    if len(cfts) > 0
      if cfts[0] == 'svelte'
        let cft = 'html'
      elseif cfts[0] == 'scss'
        let cft = 'css'
      else
        let cft = cfts[0]
      endif
      exe 'setf ' . cft
    endif
  endif
endfu

fu! NERDCommenter_after()
  if (g:ft == 'html') || (g:ft == 'svelte')
    exec 'setf ' . g:ft
    let g:ft = ''
  endif
endfu

There are plenty of other useful tips and tricks, but I will stop here.

If you stuck with me this far you should have a fully functional Vim setup ready for Svelte development.

Plugins Mentioned

https://github.com/evanleck/vim-svelte
https://github.com/leafOfTree/vim-svelte-plugin
https://github.com/pangloss/vim-javascript
https://github.com/yuezk/vim-js
https://github.com/junegunn/vim-plug
https://github.com/leafgarland/typescript-vim
https://github.com/HerringtonDarkholme/yats.vim
https://github.com/sheerun/vim-polyglot
https://github.com/neoclide/coc-prettier
https://github.com/prettier/vim-prettier
https://github.com/preservim/nerdcommenter
https://github.com/Shougo/context_filetype.vim
https://github.com/davidtheclark/cosmiconfig

Final Words

My goal has always been to shorten the time between an idea, a thought, and its final implementation on screen. I think I've come pretty close by now by using Vim as my main editor.

However, learning Vim comes with a price. I can barely write anything outside Vim now. Short texts, no problem. Longer texts, forget it. The muscle memory is strong!

One big reason I like Vim is that it's never in my way. I don't like being distracted. It's just me, a black computer screen and my thoughts.

My final advice:

Stop jumping around, always looking for something better, and invest your time and energy into something that has proven its value by now - Vim.
Very few people can master Vim fully, but many will increase their productivity from learning just a bit of Vim and by just start using it in their daily work. Try to stick to it and miracles will happen!
Never copy someone else's config. Start with sensible defaults and build it up as you go.

If you want to learn Vim, Vimcasts is a good starting point. Godspeed.

RxJS beginner learning resources

Ilia Mikhailov — Sat, 05 Dec 2020 00:00:00 +0000

RxJS is such a wonderful technology. Seriously. It's too bad that not many people outside Angular use it. But I totally get it. The entry bar is really high. Some say it's even higher than Vim's.

I learned Vim and I learned RxJS. I didn't say it was easy. Was it worth it? 100%. The key is being persistent and not give up. If I could learn so can you!

I've compiled a list of some of the best RxJS resources for people who are just getting started on their wonderful journey to become RxJS masters.

What is RxJS?

Observables, multicast, share, subscriptions, hot, cold, async, streams, forkJoin, switchMap, concat. Oh my! Those terms alone can scare one off. But don't be afraid! Once you follow this guide everything will start making sense.

The way I like to think about RxJS is that it's a library that helps us process our data through a data-processing pipeline we define.

When you hear people talk about RxJS you often hear the word streams. Well, it kind of makes sense. The data flows through the processing pipeline just like water flows through a pipe.

RxJS also contains the word reactive in it. Let's talk about it and what reactivity means in this context. I like to think of it as the data pipeline only activates (reacts) only when we tell it to. What do I mean by that? Let me explain.

Reactivity means that we can trigger our data processing pipeline by various inputs or events that we define in the pipeline. But there is a catch. The pipeline is not activated, even when triggered by our defined events, unless we tell it that we are interested by subscribing to it. No subscribers, no reactivity, no data.

This works as a kind of pull model, even though the data is pushed through the pipeline. Let me explain. When we subscribe to our pipeline (pull), we activate the pipeline. It then activates the pipeline from the bottom all the way up by saying "Hey, we have a subscriber! Let's start working!" All the events listeners and triggers will get activated and they will start processing (pushing) data through our pipeline all the way down to us when something is triggered. When we unsubscribe, the pipeline will become inactive again, because there are no subscribers.

Does it make sense? It's reactive because it's lazy. Nothing happens until you subscribe. Only then it starts reacting (or working).

RxJS is also a declarative framework. This is another concept that can be hard to understand. With imperative (normal) programming you describe exactly what you want to happen, step by step. You give precise instructions. With declarative programming, on the other hand, you write code that describes what you want to do, but not necessarily how to do it. You say what you want, but you don't specify exactly how. It's compiler's job to figure it out. You give the compiler commands instead of telling it exactly what to do. These commands consists of RxJS operators chained together. The implementation details are abstracted away from you. You specify the desired outcome and compiler will figure it out for you.

This is good, because you are forced to work on the higher level of abstraction. The implementation details are already in place for you. Less code to write. You just have to define the desired outcome in your program and RxJS will take care of it.

Another hurdle, and maybe the hardest to jump over, is thinking in streams. Thinking in streams is super-hard and will take you some time to learn. But it's really cool once you grok it. When you finally reach that "Aha!" moment you will for sure get a rush. Suddenly, it will all make sense and you will realize how to merge, delay, filter, split and do lots of other cool things with streams.

One essential thing when learning RxJS is to take it slow and be patient. You head will hurt, for sure. Try not to get frustrated. It will all click together soon if you are persistent. Later, you will wonder why you didn't learn RxJS earlier and will be telling all your friends how cool it is and you will start prompting it in your circles.

How to use this guide

I've compiled a list of resources that helped me learn RxJS. RxJS is built into Angular, that's why many articles on the internet are Angular based. But you can ignore all Angluar stuff and concentrate only on the juicy RxJS parts.

The guide is broken down into different sections. Start at the top, it will help you learn the core concepts. Later, feel free to jump around to the articles that catch your attention.

When you read an article and learn a new concept, it's not guaranteed to be crystal clear at first. Come back to it sometimes later and re-read it.

After you learn a new concept or operator, try to play around with it to get that hands-on feeling. Spend 20-30 minutes on it. It will be time well invested.

Also, many of the articles included are on Medium. Sorry about that.

Note on Svelte and RxJS

I am a Svelte fan, so I also threw in a couple of Svelte related articles for other Svelte fans out there. One thing about Svelte and RxJS combo is that they go very well together. I like to say that RxJS is Svelte's stores on steroids. You get 200% reactivity if you use RxJS.

Another cool thing is that you don't have to use onMount, when fetching data for example. Why? Because RxJS is lazy (reactive). Since Svelte views RxJS pipelines as Svelte stores, Svelte compiler manages subscriptions for us automatically. Now, how cool is that?!

Basics

The hardest part is getting started. RxJS has many operators, but you only need to learn a handful of them to be productive. Once you learn them, others will start making sense.

The introduction to Reactive Programming you've been missing

Classic introduction to Reactive Programming. This should be your starting point. It's a little dated, but explains the concepts well and teaches you how to think in streams.

Recreating a classic FRP tutorial with Svelte and RxJS

My own take on the tutorial above with Svelte and newer version of RxJS. Plus I went a bit further than the original article by removing code duplication.

Rxjs Ultimate Book

Good and short introduction to RxJS in form of free online book. Highly recommended!

If Svelte and RxJS had a baby

I explain why Svelte and RxJS is such a nice combo with a few simple examples.

Getting Started With RxJS

Short article that gives a digestible overview of RxJS and concepts with a few code examples.

Thinking reactive with the SIP principle

Nice article that teaches you to think reactively with RxJS. I like to think of RxJS operators as Lego pieces that you assemble into something larger.

RxJS, where is the If-Else Operator

Coming from imperative background you might wonder where the if statement is. Well, there is no if statement sort of. Instead you use operators like map and filter to achieve the desired branching logic.

Understanding hot vs cold Observables

Hot and cold observables. You will hear it a lot when learning RxJS and will most likely get burned by it sometimes. This short article explains the concepts very well.

RxJS: Understanding the publish and share Operators

This article explains in-depth how to turn cold observarbles into hot. Heavy reading, but an excellent reference.

Understanding RxJS Subjects

RxJS subjects is another concept that you must understand. They are really useful. This article explains subjects on the higher level.

RxJS Subjects Explained with Examples

Good code examples of RxJS subjects. A follow up article to the one above.

Comprehensive Guide to Higher-Order RxJs Mapping Operators

Mapping operators are the core of RxJS and there are quite a few of them. This article explains them well.

Understanding RxJS map, mergeMap, switchMap and concatMap

Another excellent article on various RxJS mapping operators. A must read!

RxJs Error Handling: Complete Practical Guide

You will get errors and exceptions when working with RxJS and you need to know how to handle them. This in-depth article explains how to deal with errors the RxJS way.

Top Ten RxJS Concepts

Little dated, but still very good RxJS concepts overview from Fireship. With complementary video too!

Intermediate

Once you get down the basics your imperative mind will still struggle to translate it to declarative thinking. You need to revisit the concepts and examine them closer, more in-depth.

After you learn the basics, you only need to learn a handful of operators. Like, really learn them. Especially different mapping operators. Higher-order observables can be tough to grasp.

Below is a collection of intermediate resources. They all require basic RxJS knowledge. Without it they will be either overwhelming or will just not make any sense to you.

Thinking in nested streams with RxJS

Learn how to work with higher-order observables aka nested streams.

RxJS. Transformation Operators in Examples (part 1)

Very good breakdown of the transformation operators such as different buffer and concat operators. Clear code examples.

RxJS. Transformation Operators in Examples (part 2)

Second part of the transformation operators. This time various merge, scan, group and window operators. Excellent code examples!

Combining Observables with forkJoin in RxJS

ForkJoin is RxJS version of Promise.all. It's really useful to have when you have to deal with parallel HTTP requests for example.

Deep Dive Into The RxJs switchMap Operator - How Does it Work? A Less Well-Known Use Case (selector functions)

SwitchMap is one operator that you will use often. This is a nice breakdown of how it works using HTTP requests examples.

RxJS: merge() vs. mergeAll() vs. mergeMap()

Merge is also one of the frequently used operators. Make sure you understand all the different variations of it.

The magic of RXJS sharing operators and their differences

Explains the sharing operators in detail. Those cold vs hot observable concepts.

Creating Custom Operators in RxJS

Learn how to create custom observables in RxJS. Helps you understand and solidify your RxJS observable concepts.

Getting to Know the Defer Observable in RxJS

Defer operator is really handy. It might not be something you will use often, but it's still very important operator to know.

Create a tapOnce custom Rxjs Operator

Continuing on the topic of custom RxJS operators. Here is a very good article explaining how to create a custom tapOnce operator. You will be using tap operator a lot when you need to debug your pipelines and see what data flows through them.

Showing a loading spinner delayed with rxjs

Clean example of how to show a loading spinner while waiting for something. I am sure you will want to show a loading spinner in your apps.

Debounce with vanilla JavaScript or RxJS

Examples of debounce using plain JS and RxJS. Which one is better? You be the judge.

Thinking Reactively with RxJS

A text transcript and source code of the paid RxJS course on Egghead.io. Covers lots of ground!

Advanced

Below are some advanced topics and tips. Take a look at them when you are really sure you understand the core concepts.

RxJS: Understanding Expand

Learn the expand operator with guitar delay pedal example. Very cool!

RxJS examples of the day (part 1)

Good examples of how solve problems in the most effective ways when using RxJS. Lots of learning opportunities.

RxJS: iif is not the same as defer with ternary operator

Comparison between iif and defer and when to use what.

Building a safe autocomplete operator in RxJS

RxJS is really handy for autocomplete. Learn how to build a custom autocomplete operator.

Thinking reactively in Angular and RXJS

Learn how to think reactively by building a calendar app.

Other Interesting Resources

Learn RxJS

Best RxJS reference with good examples. My goto place when I need to look up an operator.

RxJS-fruits

Fun game to learn RxJS. You have to code your way through.

RxJS Marbles

RxJS is usually explained with the help of marble diagrams. This is a good interactive reference to many RxJS operators.

ThinkRx

Another interactive tool slash reference that will help you understand operators with code examples and marble diagrams.

reactive.how

Lots of good resources and short interactive animations comparing different operators together. Site feels a bit messy, but the information is really good.

RxJS & Firebase 101

Firebase has really nice RxJS bindings. This article explains the basics.

Introducing BLoC Pattern with React and RxJS

BLoC pattern originated in Dart language, but can be used in other frameworks too. Here is a simple example with RxJS in React.

RxJS Cheatsheet VS Code extension

Handy VSCode extension. View RxJS operator documentation in-place.

https://github.com/AlexAegis/svelte-minesweeper

Cool classic Minesweeper clone built in Svelte, RxJS and TypeScript. Lots of learning opportunities by studying the code.

Videos

If videos are your thing, here are some of the best ones.

You will learn RxJS

Essential talk that explains observables by building observables. If you plan on watching one talk only, make it this one.

Learn RxJS in 60 Minutes for Beginners

A nice crash course that covers the basics of RxJS. Covers lots of ground.

Mastering the Subject: Communication Options in RxJS | Dan Wahlin

A really good explanation of RxJS subjects and how you can use them to communicate between different application components.

The Magic of RxJS - Natalia Tepluhina | JSHeroes 2019

Shows how you can use RxJS to build a Pong game. Heavy code, but very inspirational talk!

Data Composition with RxJS | Deborah Kurata

Really good talk that explains how you can use RxJS to fetch data and do cross-component communication. A must watch!

Thinking Reactively: Most Difficult | Mike Pearson

Learn how to think reactively by building a typeahead search. Very good talk for RxJS newbies.

Understanding RxJS Error Handling

Excellent talk on different exception handling strategies in RxJS.

Why Should You Care About RxJS Higher-order Mapping Operators?

Explains higher-order RxJS mapping operators with clear examples that all can understand.

I switched a map and you'll never guess what happened next

Fun interactive talk that explains mapping operators with the help of hiring agency example.

RxJS Advanced Patterns – Operate Heavily Dynamic UI’s | Michael Hladky

Advanced concepts talk that goes very deep. Expect to scrub a lot in order to understand everything.

Personal tips

Here are some tips from me that can help you on your RxJS learning journey.

Don't give up! If will be hard, but if you give it time, it will all come together soon. Things will click, I promise!
Use tap operator for debugging your pipelines. Inject tap(console.log) anywhere in your pipeline to view the data flowing through it.
You will probably start by composing very large pipelines. It's OK. Later, try to write small single-purpose operators instead and learn how to combine them. View them as Lego bricks.
Learn of, from, merge, BehaviourSubject, combineLatest, startWith and all the mapping operators. They will give you a solid base to stand on.

Exercises

You can read articles and watch videos all you want, but in order to truly learn and understand you have to do some coding. Here are some good problems you can try to tackle with RxJS.

Timer App

Try to create a simple timer app. You should be able to start, stop and reset the timer. Bonus points: be able to set a countdown time.

Typeahead Search

Try to implement a simple typeahead TV show search by using Episodate API.

Closing words

RxJS is a wonderful technology, but it's not widely adopted yet. One of the main reasons might be the lack of good learning resources. Hopefully this resource will help your discover its super-powers.

My main advice is to take it slow and don't give up! It will all click soon enough if you are persistent. Soon you will be wondering how you even could do something without RxJS and will mutter for yourself how easy you could have solved the problem if only this project used RxJS.

How to send transactional HTML emails with Mailgun, Handlebars and Firebase

Ilia Mikhailov — Wed, 25 Nov 2020 00:00:00 +0000

If you are building any serious app chances are big that you have to send some emails. I needed to send transactional emails for a web app I am building, so I reached for the trusted Mailgun.

The app itself is based on Firebase and Firebase Functions was an obvious choice for sending emails. What was not so obvious is how to put everything together. I went through the pain and finally figured it out.

Below are my notes on how I got everything to work with TypeScript using Mailgun, Handlebars templates for HTML emails and Firebase Functions.

Firebase Functions Setup

I assume here that you already have a Firebase project set up with the local Firebase emulator running. If not, you can follow my guide - Smooth local Firebase development setup with Firebase emulator and Snowpack. It targets Svelte, but you can skip those parts if you are using some other framework or technology.

Mailgun Setup

There are many transactional email providers, but I chose Mailgun. Mostly because of their cool name and logo, and also because they have a generous free quota (5K emails/month) and a nice Javascript SDK.

I won't go through setting and configuring Mailgun, DNS and all that jazz. They already have good documentation on how to do it. Instead, I will concentrate on wiring everything up in code.

There are several Mailgun libraries on NPM, but we will go with the official one. It's written in Javascript and if you are using Typescript you have to install the types.

$ npm add mailgun.js @types/mailgun-js

Because Mailgun SDK is written in Javascript you have to add esModuleInterop to your tsconfig.json.

{
  "compilerOptions": {
    "module": "commonjs",
    "noImplicitReturns": true,
    "noUnusedLocals": true,
    "esModuleInterop": true,
    "outDir": "lib",
    "sourceMap": true,
    "strict": true,
    "target": "es2017"
  },
  "compileOnSave": true,
  "include": [
    "src"
  ]
}

All right! We are ready to roll!

Writing the email sender function

To keep code clean we will keep the email sending logic in a separate file. Create a new email.ts file in the src directory.

// email.ts

import * as functions from 'firebase-functions';
import Mailgun from 'mailgun-js';

const apiKey = 'mailgun-api-key';
const domain = 'mg.example.com';

const mg = new Mailgun({ apiKey, domain });

export const send = (subscribers: string[]) =>
  mg.messages().send({
    from: 'Mailgun Test <noreply@mg.example.com>',
    to: subscribers,
    subject: 'Mailgun test',
    text: 'Hello! How are you today?',
    html: '<h1>Hello!</h1><p>How are you today?</p>'
  });

So far, so good. With this code we can send an email to a bunch of subscribers whose email addresses are passed in as a list of strings.

Firebase Remote Config

Mailgun SDK requires an API key to send email. While you can hardcode it in your code, as we did in the example above, you should never do it. Instead, we can leverage Firebase Remote Config for this and keep our Maingun API key securely stored in it.

$ firebase functions:config:get > .runtimeconfig.json

If you already don't have anything there you will get and empty JSON file. Let's add our Mailgun API key to it.

{
  "mg": { "key": "your-mailgun-api-key" }
}

NOTE: to set this value in production later you can use the command below.

$ firebase functions:config:set mg.key="your-mailgun-api-key"

Also, make sure to keep all your config keys lowercase or Firebase will complain!

Now, when the Firebase emulator starts it will pickup the local config. This means that we can get the key from the functions config.

// email.ts

import * as functions from 'firebase-functions';
// ...

const apiKey = functions.config().mg?.key;

Our basic email function is now done. Let's continue with setting up our Handlebars templates.

HTML email templates with Handlebars

HTML email design is hard. It's like going back to the 90s again. Tables and all. Luckily there are plenty of apps that can help you with that. Maybe you even have an old copy of Adobe Dreamweaver laying around somewhere? If you a feeling adventurous.

Jokes aside, if you want to learn more about HTML email design I can highly recommend reading An Introduction To Building And Sending HTML Email For Web Developers on Smashing Magazine.

But, we are aiming for the MVP here as this article's focus is on the technical implementation and not on email design.

My goal was to keep the email templates separate from code and Handlebars is a good fit for that. With that said, it was not as straight forward as I first thought.

Handlebars.js is one of the templating languages that allows you to precompile your templates, so you can later import them in code. It took me a while to get it right, but here is how you do it.

First, let's install Handlebars and npm-run-all utility package that we will use for the precompile step.

$ npm add handlebars npm-run-all

Next we need to create two Handlebars templates. One for html emails and one for text emails.

Create an emails folder in the root of the project and then create two files in it - html.handlebars and text.handlebars.

{{!-- html.handlebars --}}

<h1>{{title}}</h1>

<p>{{body}}</p>

<p>All the best, John</p>

Text template is needed for email clients that can't display HTML. I am looking at you Mutt!

{{!-- text.handlebars --}}

{{title}}

{{body}}

All the best, John

Now that we have created the templates we need to precompile them with this command.

$ npx handlebars emails/ -f src/templates.js -c handlebars/runtime

It compiles the templates into templates.js module and also includes the reference to handlesbars/runtime module that is needed for some reason.

Now you can import templates.js in your code and both text and html templates will be available.

// email.ts

import * as functions from 'firebase-functions';
import Mailgun from 'mailgun-js';

import * as Handlebars from 'handlebars/runtime';
import './templates';

const apiKey = functions.config().mg?.key;
const domain = 'mg.example.com';

const mg = new Mailgun({ apiKey, domain });

// import our email and text precompiles templates
const html = Handlebars.templates['html'];
const text = Handlebars.templates['text'];

export const send = (subscribers: string[]) => {
  const data = { title: 'Mailgun Test', body: 'How are you?' };

  return mg.messages().send({
    from: 'Mailgun Test <noreply@mg.example.com>',
    to: subscribers,
    subject: data.title,
    text: text(data),
    html: html(data),
  });
};

Our email send function is now complete, but let's streamline our development environment a bit, so that Handlebars templates are precompiled automatically before we build our functions.

Change the scripts section in functions' package.json to this.

"scripts": {
    "build": "run-s build:templates build:tsc",
    "build:tsc": "tsc",
    "build:templates": "handlebars emails/ -f src/templates.js -c handlebars/runtime",
    "serve": "npm run build && firebase serve --only functions",
    "shell": "npm run build && firebase functions:shell",
    "start": "npm run shell",
    "deploy": "firebase deploy --only functions",
    "logs": "firebase functions:log"
  },

When we now execute npm run build Handlebars will compile the templates first before we compile function. This is done with run-s (s is for serial) which is a part of the npm-run-all utility package.

Wiring everything together

Now that we have all the different parts done, let's wire them all together.

// functions/src/index.ts

import * as functions from 'firebase-functions';
import { send } from './email';

export const sendEmail = functions.https.onCall(async data => {
  const { subscribers } = data;

  try {
    await send(subscribers);
    return { ok: true };
  } catch (err) {
    return { ok: false, error: err.message };
  }
});

That's it! Now you can send transactional emails with Mailgun through Firebase Functions. I kept the example minimal in order to keep things simple, but you can fetch data from Firestore or send the email in the Firebase trigger functions. Imagination is the limit!

BONUS: Firebase Functions Emulator Startup

If you what to start both Firebase emulator and function compilation watch, when you start the project, change the scripts section of your main project's package.json to this.

"scripts": {
  "build": "run-p build:*",
  "build:functions": "cd functions && npm run build",
  "firebase:deploy:functions": "firebase deploy --only functions",
  "firebase:start": "firebase emulators:start --only functions",
  "start": "run-p watch:* firebase:start",
  "watch:functions": "cd functions && npm run watch"
},

Libraries Mentioned

Conclusion

This is just one way to send transactional emails from Firebase functions. To keep templates separate from code we had to precompile our email templates as Firebase functions can't deal with file system very well. I am sure there are other templating languages that support precompilation, but Handlebars is good enough for the task.

You can find complete example code on Github.

https://github.com/codechips/firebase-functions-mailgun-handlebars-example

Thanks for reading!

Transforming an object to array in JavaScript

Ilia Mikhailov — Mon, 09 Nov 2020 00:00:00 +0000

When working with objects in JavaScript sometimes it's convenient to transform them to arrays. In this short post I will show you how to do it in plain JavaScript and also with Rambda.js.

Let's say that we have a nested JavaScript object that looks like this. If you work with Firebase Firestore, or some of Google Cloud Platform's or AWS API, you might have stumbled on structures like these.

const obj = {
  id: 'one',
  services: {
    'service-foo': {
      slug: 'foo',
      public: true,
      readonly: true,
    },
    'service-bar': {
      slug: 'bar',
      public: false,
      readonly: true,
      users: ['john', 'jane'],
    },
    'service-baz': {
      slug: 'baz',
      public: false,
      readonly: false,
      users: ['bo', 'bill', 'brooke'],
    },
  },
};

Say we want to display the services property as a list on the page. While it's possible to loop over the object itself, it's more convenient to loop over a list that looks like this.

[
  {
    id: 'service-foo',
    slug: 'foo',
    public: true,
    readonly: true,
    users: [ 'frank', 'finn', 'fernando' ]
  },
  {
    id: 'service-bar',
    slug: 'bar',
    public: false,
    readonly: true,
    users: [ 'john', 'jane' ]
  },
  {
    id: 'service-baz',
    slug: 'baz',
    public: false,
    readonly: false,
    users: [ 'bo', 'bill', 'brooke' ]
  }
]

How can we transform our our services property object to an array?

Transforming with plain JavaScript

One obvious way is to do it in plain JavaScript. Like this.

const transform = obj => Object.keys(obj).map(id => ({ id, ...obj[id] }));

console.log(trasform(obj.services));

We map over object's keys and construct a new object consisting of the object's key and its properties with the help of the ES spread operator.

Transforming object with Rambda.js

I was curious how to achieve the same results with Rambda - a functional programming library for JavaScript.

Turns out there are two ways to do it.

First one is to use Ramda's pipe operator.

const R = require('rambda');

const transform= R.pipe(
  R.toPairs,
  R.map(([id, props]) => ({ id, ...props }))
);

console.log(trasform(obj.services));

Second is to use Ramda's compose operator.

const R = require('rambda');

const transform = R.compose(
  R.map(([id, props]) => ({ id, ...props })),
  R.toPairs
);

console.log(trasform(obj.services));

Both results in the same output. It's only a matter of taste. If you are coming form an FP background, compose will look more natural to you.

Let's break down Rambda's toPairs operator. Maybe a better name for it would be toTuple.

console.log(R.toPairs(obj.services));

[
  [
    'service-foo',
    { slug: 'foo', public: true, readonly: true, users: [Array] }
  ],
  [
    'service-bar',
    { slug: 'bar', public: false, readonly: true, users: [Array] }
  ],
  [
    'service-baz',
    { slug: 'baz', public: false, readonly: false, users: [Array] }
  ]
]

The toPairs operator loops over object's keys and returns key and property a list with two items in it - [key, prop].

In functional programming you often work with lists as they are easier to manipulate.

Rambda - pipe vs compose

What the difference when it comes to the two composition operators in Rambda - pipe and compose? It's subtle. In my opinion it's a matter of taste.

The pipe operator feels most intuitive to developers. It works like a pipe in Unix (ls -l | grep js), passing the results from one function to another in the chain from left to right. First function can take multiple arguments, but the rest of the functions in the chain can only have one argument as input. It reminds me a lot about the proposed pipeline operator in JavaScript.

The compose operator does the opposite of pipe. It performs its operations right to left.

I find it intuitive to think of it as the Russian Doll pattern - f4(f3(f2(f1([1,2,3])))), where each function is called inside out.

There are probably a few more ways to transform an object to array. Let me know then so I can learn something new.

Snowpack for Svelte development revisited

Ilia Mikhailov — Fri, 30 Oct 2020 00:00:00 +0000

As I am writing this I realize that I have no good introduction. This is another post about finding the best bundler for Svelte and this time it's Snowpack's turn to be evaluated.

Building a good bundler is not easy. Building a fast bundler is almost impossible. Mad props to those who dare.

I discovered Snowpack before version 2 was officially released and was very excited about it. Today I decided to revisit it to see how and if things have changed since.

My goal is to compare different bundlers for Svelte development in order to find the best one. I've already tested Vite, Svite and now it's Snowpack's turn.

Requirements

For the purpose of evaluation I created a simple web app. Its functionality is simple. You press a button and it fetches a random Kanye West tweet from Kanye as a Service.

While simple, the application has interesting parts.

Svelte components are written in Typescript. I want to see if transpiling and type checking works correctly for TS.
External Svelte library. Not all bundlers support libraries written in Svelte efficiently.
External library dependency. I want to see if a bundler supports tree shaking when bundling for production.
External Assets. It should be possible to import SVG, PNG, JSON and other external assets in our code.
PostCSS with TailwindCSS. A good bundler should make it easy to work with SASS and PostCSS.
Business components in Typescript. Typescript is here to stay. A good bundler should support it out-of-the-box.

I also have a list of my own requirements when it comes to bundlers.

It must be fast
It must support Typescript
It must support PostCSS
It must produce small and efficient bundles
It must produce correct sourcemaps for debugging
It should support HMR (Hot Module Replacement)

Let's see if Snowpack can satisfy all of them.

Bootstrapping the app

Snowpack comes with many official framework templates that you can use as base for your apps. Since the app is written in TypeScript we will use @snowpack/app-template-svelte-typescript. It's not listed on the website, but in Github.

$ npx create-snowpack-app svelte-snowpack-typescript \
  --template @snowpack/app-template-svelte-typescript --use-pnpm
$ cd svelte-snowpack-typescript
# add test app's dependencies
$ pnpm add -D date-fns svelte-inline-svg
$ pnpm start

I like how Snowpack lets me specify the package manager. pnpm, the package manger I often use, is not in the main documentation, but I found the option somewhere in Github.

Dev server starts instantly and Snowpack is nice enough to open the browser for me. I appreciate it, but I don't like it or need it.

Another thing I like about Snowpack is that it uses npm start script and not dev to start everything up. The npm run dev command is so 2015, right?

I also noticed that app template's config file has changed from JSON to JS. I like it because it makes it easy to comment and do other advanced JS gymnastics.

module.exports = {
  mount: {
    public: '/',
    src: '/_dist_',
  },
  plugins: [
    '@snowpack/plugin-svelte',
    '@snowpack/plugin-dotenv',
    '@snowpack/plugin-typescript',
    [
      '@snowpack/plugin-run-script',
      {cmd: 'svelte-check --output human', watch: '$1 --watch', output: 'stream'},
    ],
  ],
  install: [
    /* ... */
  ],
  installOptions: {
    /* ... */
  },
  devOptions: {
    // don't open browser
    open: 'none',
    // don't clear the output
    output: 'stream'
  },
  buildOptions: {
    /* ... */
  },
  proxy: {
    /* ... */
  },
  alias: {
    /* ... */
  },
};

So far so good.

What's in the box?

Let's see what files Svelte template generates for us.

$ ls -1
babel.config.json
jest.config.js
jest.setup.js
LICENSE
node_modules
package.json
pnpm-lock.yaml
public
README.md
snowpack.config.js
src
svelte.config.js
tsconfig.json
types

Not bad. I don't know why Babel config has to be explicit and I am usually not writing any unit tests, so jest has no use for me. But other that that it looks nice and clean.

The app entry file comes with an explicit HMR section. I like that it's explicit and how it tells you where to find more information. Good!

import App from "./App.svelte";

var app = new App({
  target: document.body,
});

export default app;

// Hot Module Replacement (HMR) - Remove this snippet to remove HMR.
// Learn more: https://www.snowpack.dev/#hot-module-replacement
if (import.meta.hot) {
  import.meta.hot.accept();
  import.meta.hot.dispose(() => {
    app.$destroy();
  });
}

By now I've copied the code from my test web app, added missing dependencies and tried to start the dev server. Things don't quite work yet.

External Svelte libraries

This is where I hit the first road block. Looks like Snowpack uses pkg.module file if it exists. The svelte-inline-svg library I am using had the module property defined, but the file was missing in the NPM package. Showpack borked on this. I wish that it could have fallbacks in place and try with something else if the file is missing. The author of the SVG library has fixed it after I filed a bug report.

PostCSS + TailwindCSS

Snowpack has no PostCSS support out-of-the box, because in Snowpack it's all about plugins and build scripts, but it offers instructions on the main documentation page on how to enable PostCSS. But turns out there is some ambiguity. The main documentation webpage tells one thing while Github tells another. Which one to trust?

Alright, let's go with the second one and use Snowpack's plugin-postcss. Not sure I understand why I have to explicitly install postcss and postcss-cli. Wouldn't it be better if they were baked into the Snowpack's PostCSS plugin?

$ pnpm add @snowpack/plugin-postcss postcss postcss-cli

Next, we need to add the plugin to snowpack.config.js.

...
plugins: [
    ...
    '@snowpack/plugin-postcss',
],
...

Talking about plugins. Snowpack has quite strange plugin configuration. You can either supply plugin as string, or as an array if plugin needs some arguments, where first item is the name of the plugin and second is an object of the arguments that will be passed to the plugin.

[
    '@snowpack/plugin-run-script',
    { cmd: 'svelte-check --output human', watch: '$1 --watch', output: 'stream' },
],

Let's install and setup Tailwind and friends.

$ pnpm add -D tailwindcss postcss-preset-env
$ pnpx tailwind init

Replace Tailwind configuration file with the following contents.

// tailwind.config.js

module.exports = {
  future: {
    removeDeprecatedGapUtilities: true,
    purgeLayersByDefault: true,
  },
  experimental: {
    uniformColorPalette: true,
    extendedFontSizeScale: true,
  },
  purge: {
    content: ['./src/**/*.svelte', './public/*.html'],
    whitelistPatterns: [/svelte-/],
  },
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
};

And postcss.config.js with this contents.

// postcss.config.js

const tailwind = require('tailwindcss');
const purge = require('@fullhuman/postcss-purgecss');
const cssnano = require('cssnano');
const presetEnv = require('postcss-preset-env')({ stage: 1 });

const plugins =
  process.env.NODE_ENV === 'production'
    ? [tailwind, presetEnv, cssnano]
    : [tailwind, presetEnv];

module.exports = { plugins };

Environment Variables

Svelte template comes with dotenv pre-packaged as Snowpack plugin. This is nice as it doesn't require a working dotenv environment in the shell.

The ES2020 import.meta.env works out of the box, but not in my Vim editor.

VS Code works fine and you get autocompletion too. I figured that coc-svelte plugin I am using is way behind VS Codes Svelte extension. As soon as I forked and updated dependencies, Vim stopped complaining.

NOTE: If you are using Vim, coc.nvim and coc-svelte extension, you can use mine. It's more up-to-date than the original one @codechips/coc-svelte.

You have to prefix all env variables with SNOWPACK_ if you want them to be accessible in the app. Most bundlers today follow this convention in order to avoid environment variable clashes.

For my app I had to create an .env.local file so that dotnenv could pick it up, but any dotenv convention works.

# .env.local
SNOWPACK_PUBLIC_KANYE_API=https://api.kanye.rest

Snowpack and svelte.config.js

As I understand svelte.config.js file is mostly only used by code editors for autocompletion. Not with Snowpack. Snowpack is one of the few bundlers that relies on that file to exist. It's used by its Svelte plugin. Good thing that it comes with the template.

Snowpack, Svelte and TypesScript

TypeScript is nice, but getting TypeScript configuration right is usually a game of trial and error for me. Snowpack's Svelte template has a dependency on the @tsconfig/svelte NPM package, but from what I can see it's not used anywhere?

The svelte-inline-svg module does not come with any TypeScript declaration. We need to fake it locally.

Create svelte-inline-svg.d.ts in the types directory with the following contents.

declare module 'svelte-inline-svg';

By the way, I really like how the svelte-check tool, which comes already injected into the build pipeline, warns me about it and provides instruction on what to do.

I also like that Snowpack has a dedicated types directory for your own TypeScript definitions. Somehow, I always struggle to configure type paths. Snowpack is the first bundler that makes this clear for me.

Building

The test app is now finally working! Lets build it for production.

$ pnpm build
> snowpack build
...

[@snowpack/plugin-typescript] src/index.ts(2,17): error TS2307: Cannot find module './App.svelte' or its corresponding type declarations.
[@snowpack/plugin-typescript] Error: Command failed with exit code 2: tsc --noEmit
src/index.ts(2,17): error TS2307: Cannot find module './App.svelte' or its corresponding type declarations.
 ERROR  Command failed with exit code 1.

Oops. Something is wrong, but what? I actually never figured out what, so I recreated the whole project from scratch, which helped. Who told you that this was going to be easy, right?

When building Snowpack shows you a nice stats table of all the build artifacts.

But what's in the build?

tree -h build
build
├── [4.0K]  _dist_
│   ├── [1.4K]  App.js
│   ├── [4.0K]  assets
│   │   ├── [ 899]  usa.svg
│   │   └── [  40]  usa.svg.proxy.js
│   ├── [ 14K]  index.css
│   ├── [ 15K]  index.css.proxy.js
│   ├── [ 334]  index.js
│   ├── [1.5K]  Time.js
│   ├── [ 539]  timer.js
│   ├── [ 721]  Wisdom.css
│   ├── [1.0K]  Wisdom.css.proxy.js
│   └── [5.9K]  Wisdom.js
├── [1.1K]  favicon.ico
├── [ 882]  index.html
├── [1.1K]  logo.svg
├── [  67]  robots.txt
├── [4.0K]  __snowpack__
│   └── [ 126]  env.js
└── [4.0K]  web_modules
    ├── [4.0K]  common
    │   └── [ 16K]  index-2f302f93.js
    ├── [ 82K]  date-fns.js
    ├── [ 273]  import-map.json
    ├── [4.0K]  svelte
    │   ├── [ 448]  internal.js
    │   ├── [2.0K]  store.js
    │   └── [ 308]  transition.js
    ├── [4.9K]  svelte-inline-svg.js
    └── [  59]  svelte.js

6 directories, 24 files

You have __dist__ folder with all your application files, __snowpack__ folder with the env variables, and web_modules folder with all the dependencies.

Snowpack bundles your assets (CSS, SVG) files as JS files, the .proxy.js ones. I wonder why it also puts raw SVG and CSS file in the build directory if they are not used in production.

The dependencies are not bundled, but server to browser as ES modules. After all, Snowpack is an ESM bundler.

This has its advantages and drawbacks. The development is super-fast as only the files changes need to be recompiled and reloaded. The files and dependencies are not optimized and served as is, which leads to many more requests if you have many dependencies and also to larger downloads as you need to download the whole module even if you only use one function in it.

You might need to only do it once on the first load, then the files might be cached, but I am not the expert on this.

Bundling a Snowpack project

Ah! The ultimate test for a bundler. How efficient bundles a bundler can produce. Snowpack doesn't have bundler support built-in, but there are some plugins that we can use.

Some time while ago Snowpack released an optimization plugin. It's not a bundler plugin, but more of a minifier. It helps you minify CSS, HTML and JS. From what I have read, this plugin uses ESBuild's minifying functionality and from what I understand it's almost on par with Rollup's.

Enough talking, let's test!

$ pnpm add -D @snowpack/plugin-optimize

We need to add it to the list of plugins in snowpack.config.js and do a new build.

Strange. I see no difference in the stats table output.

The terminal output is saying that file size didn't change, but if I look at the actual file on disk it's actually 21K and not 83K as Snowpack tells me.

$ tree -h build
build
├── [4.0K]  _dist_
│   ├── [ 768]  App.js
│   ├── [4.0K]  assets
│   │   ├── [ 899]  usa.svg
│   │   └── [  40]  usa.svg.proxy.js
│   ├── [5.0K]  index.css
│   ├── [ 14K]  index.css.proxy.js
│   ├── [ 251]  index.js
│   ├── [ 860]  Time.js
│   ├── [ 305]  timer.js
│   ├── [ 554]  Wisdom.css
│   ├── [ 893]  Wisdom.css.proxy.js
│   └── [2.7K]  Wisdom.js
├── [1.1K]  favicon.ico
├── [ 416]  index.html
├── [1.1K]  logo.svg
├── [  67]  robots.txt
├── [4.0K]  __snowpack__
│   └── [ 126]  env.js
└── [4.0K]  web_modules
    ├── [4.0K]  common
    │   └── [6.1K]  index-2f302f93.js
    ├── [ 21K]  date-fns.js
    ├── [ 273]  import-map.json
    ├── [4.0K]  svelte
    │   ├── [ 421]  internal.js
    │   ├── [ 564]  store.js
    │   └── [ 217]  transition.js
    ├── [4.8K]  svelte-inline-svg.js
    └── [  54]  svelte.js

6 directories, 24 files

Weird. I don't know if it's cached somewhere or if the numbers are showing something else.

Testing @snowpack/plugin-webpack

Looks like Snowpack's plugin-optimize does some light optimization, but Showpack also has a real official bundler plugin - plugin-snowpack. It actually use to have an official Parcel plugin, but looks like it has been removed.

Last time I tried Snowpack's Parcel and Snowpack plugin none of them worked. Has anything changed? Let's try Webpack plugin.

Nope. Still getting the same "'babel-loader' not found" error from it.

Entry module not found: Error: Can't resolve 'babel-loader'

It installed it, but it didn't help. I give up. Don't feel like I want do go down the rabbit hole.

As of Rollup, no official Rollup plugin exists (yet), but Svelte crew promised that it's coming soon.

Building an SWC compiler plugin for Snowpack

Snowpack is all about plugins and they have great documentation on how to build your own. They actually encourage people to build them.

I decided to test and build an SWC compiler plugin for TypeScript files to see how hard it would be. Just for fun.

Let's get dirty. Install the SWC compiler and create a plugins directory.

$ pnpm add -D @swc/core && mkdir plugins

In the new plugins directory create a file named plugin-swc.js with the following contents.

// plugins/plugin-swc.js

const swc = require('@swc/core');
const fs = require('fs');

module.exports = function (snowpackConfig) {
  // read options from the main Snowpack config file
  const useSourceMaps = snowpackConfig.buildOptions.sourceMaps;

  return {
    name: 'snowpack-swc',
    resolve: {
      input: ['.ts'],
      output: ['.js'],
    },
    async load({ filePath }) {
      // read the TypeScript file
      const contents = await fs.promises.readFile(filePath, 'utf-8');

      // transform it with SWC compiler
      const output = await swc.transform(contents, {
        filename: filePath,
        sourceMaps: useSourceMaps,
        isModule: true,
        jsc: {
          parser: {
            syntax: 'typescript',
          },
          target: 'esnext',
        },
      });

      return {
        '.js': {
          code: output.code,
          map: output.map,
        },
      };
    },
  };
};

Now, add it to the Snowpack config.

    ...
  plugins: [
    '@snowpack/plugin-svelte',
    '@snowpack/plugin-dotenv',
    '@snowpack/plugin-typescript',
    '@snowpack/plugin-optimize',
    '@snowpack/plugin-postcss',
    './plugins/snowpack-swc.js',
    [
      '@snowpack/plugin-run-script',
      { cmd: 'svelte-check --output human', watch: '$1 --watch', output: 'stream' },
    ],
  ],
...

Start the dev server and be amazed. Your TypeScript files are now being transpiled by the SWC compiler.

Well, I am not actually 100% sure about that, because Snowpack comes with ESBuild plugin baked-in and I don't know if my SWC plugin overrides it or not.

Anyhow, this was for demonstration purpose only to show how easy it is to build a plugin in Snowpack with only a few lines of code.

If you look at Snowpack's official plugins, most of them are really simple to understand and only a few hundred lines long.

I really like this plugin approach. It makes it very easy to build your own and developers have already started building all sorts of plugins.

Requirements Revisited

Sorry for getting side-tracked. The test web app now actually works. Let us revisit the list of initial requirements and see how well Snowpack did.

It must be fast. Check. Snowpack is very fast to start.
It must support Typescript. Check. Works out-of-the-box with the TypeScript plugin.
It must support PostCSS. Check. Works with PostCSS plugin.
It must produce small and efficient bundles. Nope. No bundler plugin works with Svelte.
It should be possible to import external Svelte libs. Check.
It must produce correct sourcemaps for debugging. Nope. All files are transpiled to JS.
It should support HMR (Hot Module Replacement). Check. Works great.

Plugins Mentioned

Conclusion

Snowpack's underlying build pipeline design is very good. It feels thought through.

There are a few parts that I like. I like that it uses start script as the entry point to start the dev server. It always felt more intuitive to me than npm run dev.

When the dev server is disconnected the web app does not spam Dev Tools console log trying to reconnect to the dev server.

SvelteKit, the newly announced Svelte framework that will replace Sapper, is betting on Snowpack. According to Svelte's crew they evaluated Vite.js as an alternative, but found it not to be framework agnostic enough.

Snowpack does not have any official bundler plugin that works with Svelte, but as I understand the Svelte gang will work on making a Rollup plugin. Don't know if it will be only as a part of SvelteKit's build pipeline or an official framework-agnostic Snowpack Rollup plugin.

But maybe Rollup plugin is not needed at all? From what I've read esbuild has tree shaking functionality that is almost on par with Rollup's. I don't think that it's used in Snowpack yet and don't know either if there are any plans to implement it.

As I wrote earlier, the official Webpack plugin didn't work for me, but since it's easy to build plugins in Snowpack and the documentation is good, I bet that we can expect a lot of new and interesting plugins from the developer community in the near future. Like this one for example, Svelte with Snowpack with Google Closure Compiler.

Overall, Snowpack is an interesting and future-glancing project with a helpful community and a fierce development speed. But somehow it feels like it's rushing forward a little too fast for its own good. A lot of features feel half-finished and documentation, although great, often lags behind or is outdated.

Sorry Snowpack, I like you, but I will use another bundler for my Svelte projects for now. But don't be sad! I will come and visit in a few months. I am sure it will be a nice visit.

You can find the final code here https://github.com/codechips/svelte-typescript-setups

Managing Svelte UI state with Robot FSM

Ilia Mikhailov — Sun, 11 Oct 2020 00:00:00 +0000

Ever worked with building complex UIs? If yes, you probably know how challenging it can be to keep track all UI states. It's very easy to end up with a big hairy ball of all the state variables.

If you are building semi-complex UIs Finite State Machines can help you deal with state. Learn what FSMs are and how you can use them with a simple example.

What is a Finite State Machine?

Shortly, Finite State Machine or FSM is an old, but recently rediscovered pattern, to help us deal with complex state.

The gist of FSM is that your application can only be in one state at a time. If you think about it, it actually makes sense. Just like in real life, you can only be in one state at at time. Unless you are a quark.

I find Finite State Machines a great fit when working with complex UIs. Applications are getting more and more interactive and keeping track of UI state can quickly get challenging.

What is Robot FSM?

There are currently two popular FSM libraries in JavaScript that I know of. XState and Robot.

I would say that XState is the most popular. It has a lot of features and really great documentation. However, FSM can be intimidating to learn and XState especially, because there you can achieve the same result by different ways.

If you are interested in XState, I've written an article where I used XState as a state machine for Firebase Authentication - Firebase authentication with XState and Svelte.

For this example I decided to use Robot FSM library. First, it's much smaller than XState - 1kb vs 13kb. Second, it's also easier to learn, because it has less bells and whistles.

Robot doesn't have as good documentation as XState, so you have to read between the lines and experiment a bit to understand it's concepts and how to work with it.

But that's why I am here! Hopefully by the end of this article everything will click, you will know what an FSM is and understand where you can use them.

I promise to keep things simple. Let's code!

Setting up project

First, we need to create a new Svelte project. We will use Svite with pnpm package manager to save some disk space. I find this combination the fastest way to get going.

$ npx svite@beta create -pm pnpm svelte-robot-fsm-example

We will be building a panel menu with different sections. Think tabs component, only prettier.

Next step is to create a few Svelte components.

Creating panel components

We will create a simple panel component called Section.svelte. It will take a title and a close function handler as parameters.

Close handler will be wired up to the Close button in the component. When clicked, it should hide the menu. We will also add Svelte's slide transition for some neat visual FX.

<!-- src/components/Section.svelte -->

<script>
  import { slide } from 'svelte/transition';
  export let title = '';
  export let close = () => {};
</script>

<style>
  .section {
    border-bottom: 1px solid #65b6ca;
  }
  .inner {
    position: relative;
    padding: 1em;
    margin: 0 auto;
    max-width: 100ch;
    min-height: 200px;
  }
  h2 {
    font-weight: 700;
    font-size: 3em;
  }
  .close {
    position: absolute;
    bottom: 2em;
  }
</style>

<div class="section" transition:slide>
  <div class="inner">
    <h2>{title}</h2>
    <button on:click={close} class="close">Close</button>
  </div>
</div>

Let's setup three sections in our App.svelte. Replace the file with the code below.

<!-- App.svelte -->

<script>
  import Section from './components/Section.svelte';
</script>

<style>
  .wrapper {
    font-family: sans-serif;
  }
  .container {
    margin: 1em auto;
    max-width: 100ch;
  }
  .panel {
    background-color: #b9f0fe;
  }
  .buttons > button {
    padding: 0.5em 1em;
  }
</style>

<div class="wrapper">
  <div class="heading container">
    <h1>Svelte with Robot FSM Example</h1>
  </div>

  <div class="panel">
    <Section title="One" />
    <Section title="Two" />
    <Section title="Three" />
  </div>

  <div class="buttons container">
    <button>One</button>
    <button>Two</button>
    <button>Three</button>
  </div>
</div>

If you start the app (pnpm run dev), all of the three sections should be visible. That's not something we want. Let's add some interactivity logic next.

Doing it the normal way

Adding interactivity to these panel sections is straight forward. For that we need to add three boolean variables, one for each section, and then manipulate their state.

Here is the updated App.svelte file with state variables and on:click handlers.

<!-- App.svelte -->

<script>
  import Section from './components/Section.svelte';

  // open/close state variables. one for each section.
  let showOne = false;
  let showTwo = false;
  let showThree = false;
</script>

<style>
  .wrapper {
    font-family: sans-serif;
  }
  .container {
    margin: 1em auto;
    max-width: 100ch;
  }
  .panel {
    background-color: #b9f0fe;
  }
  .buttons > button {
    padding: 0.5em 1em;
  }
</style>

<div class="wrapper">
  <div class="heading container">
    <h1>Svelte with Robot FSM Example</h1>
  </div>

  <div class="panel">
    {#if showOne}
      <Section title="One" close={() => (showOne = false)} />
    {/if}

    {#if showTwo}
      <Section title="Two" close={() => (showTwo = false)} />
    {/if}

    {#if showThree}
      <Section title="Three" close={() => (showThree = false)} />
    {/if}
  </div>

  <div class="buttons container">
    <button on:click={() => (showOne = true)}>One</button>
    <button on:click={() => (showTwo = true)}>Two</button>
    <button on:click={() => (showThree = true)}>Three</button>
  </div>
</div>

You can see that we added basic on:click handlers to buttons and we also pass in close handlers that set state variable to false.

If you've done everything right you should now be able to open and close each panel. Good times!

But what about the scenario that only one section should be visible at one time? Meaning if you open a new one, the currently visible section should close.

It's doable, but things can get pretty hairy, because you have to track individual state of every section. That's something Finite State Machines can help us with.

Let's bring in the Robot

Let's add Robot FSM library to our project.

$ pnpm add robot3

Now we need to create our Finite State Machine. We will name it panelMachine as it will be responsible for keeping track of our panel's state.

Add this code to App.svelte and I will explain it in a second.

<!-- App.svelte -->
<script>
    // ...
  import { createMachine, state, transition } from 'robot3';

  const panelMachine = createMachine({
    closed: state(
      transition('showOne', 'one'),
      transition('showTwo', 'two'),
      transition('showThree', 'three')
    ),
    one: state(transition('close', 'closed')),
    two: state(transition('close', 'closed')),
    three: state(transition('close', 'closed')),
  });

</script>

As you can see we used Robot's createMachine function to define a state machine. The machine consists of total four states - closed, one, two and three. Our first state is closed and that will be the state machine will start with. If you look carefully you can see that our state machine is just a simple dictionary.

Each dictionary value is then defined by a state function. The state function is used to define state in Robot FSM library. But what going on inside the state functions?

State function is the meat of the Robot library. It's in there that you define your state and transitions to other states. Transitions? States? What?!

Yes, I understand if you are confused and I promised to keep things simple for that reason. Let me explain.

As I wrote earlier, an state machine can only be in one state at at time. When our panel FSM is started it starts in the closed state, because it's first in the dictionary.

If you imagine that you are in the closed state you can see that inside it we have defined three transition functions. Transition function dictates the states you can go to from the state FSM that is currently in. They are used to move from one state to another.

Every transition function takes a trigger event as first argument and the destination state as second argument. You can name events however you like, but I like to prefix mine with verbs as I like to think of them not as events, but rather commands or actions. By sending an event to the state machine you command it to go to another state than it's currently in.

One important concept to understand is that you can only move those states that you have setup transitions for. So, from our closed state we can only go to states one, two or three. If you send in some other event name than showOne, showTwo or showThree our FSM will simply ignore them and just stay in the current state it is in.

Similarly, you can only go to closed state from other states by sending a close event to our state machine. Are you with me so far?

Interpreting our state machine

Alright, we have defined our state machine. Now we have to activate it by using interpret function from the Robot library.
The interpret function takes a machine and wraps it into a service that can send events into the machine to change its states. A service does not mutate a machine. Instead it creates derived machines with the current state set.

You can find the current state of the machine by the machine.current property. If you wrap it in the service it will be located under service.machine.current.

Here is the code that demonstrates how a machine service works.

// Wrap machine into a service. Every time state changes it's printed.
// A service has a `send` command that we can use to send it events.
const service = interpret(panelMachine, service => {
  console.log('current state: ', service.machine.current);
});

console.log('current state: ', s.machine.current)
// current state: closed

// Transition from `closed` state to `one` [legal]
service.send('showOne');
// current state: one

// Transition from `one` to `two` [illegal]
service.send('showTwo');
// current state: one

// Send non-existent event
service.send('foo');
// current state: one

// Transition from `one` to `closed` [legal]
service.send('close');
// current state: closed

As you can see from the example above, if we send in a valid event, that we defined in our state transition in the current state we are in, we can switch to a different state in our state machine.

Wrapping our state machine service in a Svelte store

Robot does not have Svelte support per default, but it's not hard to wire it up. For that we will can write a custom Svelte store.

import { createMachine, state, transition, interpret} from 'robot3';
import { writable } from 'svelte/store';

export const useMachine = machine => {
    const { subscribe, set } = writable({
        state: machine.current,
        context: machine.context,
    });

    const service = interpret(machine, service => {
        set({ state: service.machine.current, context: service.context });
    });

    return [{ subscribe }, service.send];
};

As you can see we defined a useMachine constructor function. It takes a Robot FSM as its argument and returns an array. First value is our custom Svelte store with our machine's context and state as two properties. Second value is the service send method. It will allow us to send events to our machine.

Let's use it in our code.

const [panelState, send] = useMachine(panelMachine);

Using state machine

We have everything we need. Next step we need to do is to replace our on:click and close handlers. We also need to use our new panelService store for state checking instead of individual state variables.

I won't bore you with all the code changes needed. Instead, here is the updated App.svelte file in all its glory.

<!-- App.svelte -->

<script>
  import Section from './components/Section.svelte';
  import { createMachine, state, transition, interpret } from 'robot3';
  import { writable } from 'svelte/store';

  // constructor function to interpret the machine and wrap
  // the FSM service into a custom svelte store.
  export const useMachine = (machine) => {
    const { subscribe, set } = writable({
      state: machine.current,
      context: machine.context,
    });

    // every time the state changes we will update our Svelte store
    const service = interpret(machine, (service) => {
      set({ state: service.machine.current, context: service.context });
    });

    return [{ subscribe }, service.send];
  };

  // create our Robot FSM definition
  const panelMachine = createMachine({
    closed: state(
      transition('showOne', 'one'),
      transition('showTwo', 'two'),
      transition('showThree', 'three')
    ),
    one: state(transition('close', 'closed')),
    two: state(transition('close', 'closed')),
    three: state(transition('close', 'closed')),
  });

  const [panelState, send] = useMachine(panelMachine);

  // close handler
  const close = () => send('close');

    // send in event to our FSM
  const toggle = (action) => send(action);
</script>

<style>
  .wrapper {
    font-family: sans-serif;
  }
  .container {
    margin: 1em auto;
    max-width: 100ch;
  }
  .panel {
    background-color: #b9f0fe;
  }
  .buttons > button {
    padding: 0.5em 1em;
  }
</style>

<div class="wrapper">
  <div class="heading container">
    <h1>Svelte with Robot FSM Example</h1>
  </div>

  <div class="panel">
    {#if $panelState.state === 'one'}
      <Section title="One" {close} />
    {/if}

    {#if $panelState.state === 'two'}
      <Section title="Two" {close} />
    {/if}

    {#if $panelState.state === 'three'}
      <Section title="Three" {close} />
    {/if}
  </div>

  <div class="buttons container">
    <button on:click={() => toggle('showOne')}>One</button>
    <button on:click={() => toggle('showTwo')}>Two</button>
    <button on:click={() => toggle('showThree')}>Three</button>
  </div>
</div>

You can see that we have replaced our individual state variables with our state machine. We have also create two handlers - close and toggle.

If you start the app now, you will notice that we can only open one panel at a time. But I must say, it's not a correct behaviour. We cannot open other panel before we close the currently open one.

Why? If you look at our machine definition you can see that the only valid transition from a panel is to the closed state. This means the only valid event we can sent to the open panel is close event.

We can actually use this knowledge to our advantage by changing our toggle handler to the following.

const toggle = (action) => {
    send('close');
    send(action);
};

Before sending our show event, we first send the close event so that our machine enters closed state.

I don't know about you, but I find it pretty elegant.

Implementing toggle functionality

But what if we want our button not only to open, but also toggle a panel's state. Meaning if the panel is currently open clicking the same button should close it.

For that we need add a guard that checks if the current state our machine matches the desired state. If it does, it just closes the panel.

const toggle = (action, state) => {
    // if current state matches desired panel state, close it
    if ($panelState.state === state) {
        send('close');
        return;
    }
    // else first close, then open desired state
    send('close');
    send(action);
};

We also need to provide the desired state in our buttons' on:click handlers.

<div class="buttons container">
    <button on:click={() => toggle('showOne', 'one')}>One</button>
    <button on:click={() => toggle('showTwo', 'two')}>Two</button>
    <button on:click={() => toggle('showThree', 'three')}>Three</button>
</div>

Let's take a look if the toggle works.

Yep. Works dandy fine! Mission accomplished.

Conclusion

Finite State Machines are hard to understand if you haven't been exposed to them before. They also offer so much more than I showed in my example.

In Robot there is also context that lets you work with state, guards that allows you to enter a state only if condition is met, invoke that helps us work with promises and sub-machines, and immediate transitions.

XState has even more to offer. It's easy to get lost if you don't have a solid understanding of the basics first.

I chose the simplest example I could think of on purpose that only shows how to setup state and transition from one state to another by sending events.

If you want to test you skills try building a tabs component. The concepts are exactly the same and you can re-use a lot of the code we have written.

When you understand the concepts and how to work with state, all other FSM concepts become easy. In the end, it's all about states, sending events and transitions.

Start simple, experiment and I can guarantee that you will quickly start seeing places in your codebase where a state machine makes sense to use. Plus, as a bonus, you will get one more powerful tool in your toolbox.

You can find the full code at https://github.com/codechips/svelte-robot-fsm-example

Thanks for reading! Now go and replace something in your codebase with an FSM FTW.

Learn Fast, Earn Fast

Ilia Mikhailov — Thu, 01 Oct 2020 00:00:00 +0000

Life is all about continuous learning. You are always learning something new whether you like it or not. If you don't, you quickly become outdated. You don't learn, you don't earn.

The world around us is spinning faster and faster. It's not only stressful enough just to keep up to date with the information, but also constantly learn something new.

The Internet is a blessing, but also a curse. There is so much information out there! It's hard to find and process it all. My children don't see me reading many books at home nowadays, but only if they knew how much text consume on a normal day! Blogs, Slack, Twitter, emails, manuals, forums, work documents. These things add up!

Everyone today is often competing on the same terms, but you can gain a competitive advantage over others by being a fast learner. This brings me to the core question of this essay: What's the fastest way to learn?

Know your learning style

Everyone is different, therefore there is no ultimate learning process. You have to find what works best just for you. Are you a visual, auditory, reading/writing or kinetic learner? You are often not only one type, but a mix of different combinations.

Of course, you can learn by using any style - doing, watching, reading, listening, but in order to maximize your learning you have to know which one of those suits you best.

I personally is definitely a reading/writing type, but I like to watch videos too in order to get a better understanding of the topic I am learning.

Podcasts are not really my thing. I can't listen to podcasts because I need to concentrate while listening. I tried to do it in bed before sleeping, but that only made me fall asleep faster.

How about watching videos? Coding videos are also not high on my list. I hate to scrub and pause in the video player, plus I want to be able to copy and try out the code while I am watching.

Note : I know there are platforms that show video and code side-by-side, but they are rare.

Reading, on the other hand, is different. It's fast. You can easily skim to the juicy parts, plus copying and pasting text is much faster than typing it.

Style vs Process

We've talked about the learning styles, but what about the process? Which process should you follow in order to learn fast?

There are a few different approaches. Some people like to dive heads down and figure things on the way. Some like to understand what they are dealing with first.

I am definitely the second type. I like to understand before I start.

Not sure how and when I finally understood this, but I've now used it for many years with great success.

My learning process

Below are the steps I normally follow in order to learn a topic as fast and as efficiently as possible. It's not rocket science, but works great for me.

Maybe it will work for you too?

1. Know what you need to learn

Before learning something it's important to know what you want, or need, to learn. What's the minimum you need to know in order to reach your goal? What questions need answers?

Often you already might have some idea or some kind of goal in you mind. Make sure you know it beforehand. It will make judging sources of information easier.

If you are not sure, go for a walk and think about it. Somehow things tend to clear up in motion.

2. Find quality information

The first thing I do is to find as much useful slash interesting information on the topic as possible. It can be blog posts, Youtube videos, official documentation, code examples, Github repositories, Github issues, Stack Overflow threads. Anything goes here. As long as you think it can help you reach your goal.

The important part in this step is to find as much information you think might be useful as possible. Don't judge it at this stage. Just skim through it quickly, if something catches your interest, keep it and continue with your quest. Go with your gut feeling here. If something seems interesting or useful, save it, otherwise scrap it.

I also often search for the bad or negative parts. Parts that people struggle with or complain about. Review posts are super useful here, even if they are only someones opinions and not necessary the truth. I try to get a sense if it worth it and if there are any existing problems or pitfalls.

Following links I find in the articles is also something I do often. If some link catches my attention I open it in a new tab.

When I feel I have enough potential sources of information I stop. At the end of this session I usually have 20-30 browser tabs open, 10-15 bookmarks and 5-10 Youtube videos added to my "Watch Later" list.

This step usually takes me 30-60 minutes.

2. Overwhelm yourself

During this phase I start to process the found information one by one. I don't go deep here. My goal is to find interesting bits of information and extract the core concepts. I usually read only a paragraph or two, maybe look some diagrams or glance briefly at some code examples.

If I had to describe the level my concentration between 1 being glancing over text and 10 being fully emerged in some text, I would say it's around 3. I am fully concentrated, but not on the whole text. My goal at this stage is to only understand the concepts and not the details. I want to get a rough idea of what this is all about.

When it comes to videos I usually play them at 1.5X speed and often forward to the parts I find interesting.

I branch out to other related things I find on the way that I don't yet understand.

I do this to the point where I am feeling completely lost and nothing makes sense any more.

This phase usually takes me between 1-5 hours depending on the size of the subject in question.

When my brain is completely fried with information I step away from the research phase and go and do something else. Something that doesn't require brain power.

3. Sleep on it

This is a very important step, don't skip it! It's called Background Processing. You have overwhelmed your brain. Bombed it with information. Now you have to give your unconscious mind a chance to process and sort it all. Go to bed early and try to get 7-8 hours of good sleep.

4. Review yesterday

Now it's time to take some notes. To try to recap what you learned and make your own understanding of the subject. I usually grab a pen and paper and try to write down core concepts using lists and keywords. Sometimes I draw a sloppy mind map. Remember, this is only for you. Nobody will read this!

Here, I am using pen and paper. It allows me to draw doodles and other stuff and it's fast too. Plus, physically writing it down on paper has a totally different effect than typing it out on a computer. It feels more free form and your brain processes this differently. At least that's what I've noticed.

5. Distill everything

You mind has already background-processed all the information. You helped it structure it further by your review. Things and concepts suddenly start to make sense. Look at you notes and rewrite them once again, but this time only picking out the core parts and concepts.

6. Synthesize important parts

Now that you have an idea of the concepts and all the dots are connected, think through what is important. What concepts, terms, patterns have you learned? Try to identify them.

7. Play around

It's time to have some fun. Try to do something very simple. Baby steps. There is no pressure at this stage. You are in exploration mode.

Once you get something going, try to expand it. Do some more, play around. View it as POC. You are only trying to do something here. There are no "musts."

While playing around and getting stuck you will notice that you somehow you already know where to look for the solution to your problem. Either from the "overwhelm" session or you will somehow know how and where to search for the solution.

Again, thanks to the power of your mind and its background-processing ability. It helped you distill and internalize the core concepts and connect all the dots.

8. Do the work

It's now time to do the real work. Here I often use the outcome of the "play" phase as the base and somehow I already know where to look for answers I have.

Proof

All these steps can take differently long time. It depends on the size of the topic. For example, I had to learn a lot of new things in the past few weeks. One of them was Next.js.

By following my learning process I went from knowing nothing about Next.js to building a fully functional app with authentication and other bells and whistles running in production in just 3 days.

If I can do it so can you!

Useful links

Hammock Driven Development - one of my favorite talks on Youtube by Rich Hickey, creator of Clojure language. He talks about the background-processing and this is where I got the idea from.
Hacking Your Head: Managing Information Overload - a short talk by Jo Pearce on how to deal with Cognitive Load. It touches the same subjects I mention in the article, but with scientific proof.

Takeaways

Developing an effective learning process is a must if you want to stay ahead of the competition. But it's not only about learning fast, but also about learning smart.

Experiment with different approaches. Evaluate. There is no universal approach to learning. Find out what works best just for you.

The more I learn, the less I know, the less stressed I get. Because in the end it's not about knowing, but about understanding. Even if you don't know somehow you get a feeling that you have seen it before. You brain is good at making connections. By constantly learning you are building brain capital.

By having developed my own learning process I always know that I can learn fast and effectively and that keeps me calm.

Stay curious and always be learning!

Tailwind UI dropdown menu - React vs Svelte

Ilia Mikhailov — Mon, 21 Sep 2020 00:00:00 +0000

The other day I was prototyping a new internal app at work in React using Next.js. To get it off the ground quickly I used Tailwind CSS. In my app I needed to create a simple dropdown menu and I looked at the Tailwind UI example on how they did it.

Actually, creating a dropdown menu is not as simple as it sounds. First, you have to handle mouse clicks outside of it and close the menu if it's currently open. Second, you should support pressing Escape key and close the menu if it's currently open. Third, you should add nice animation to the menu so it feels more alive.

Implementing the menu in React wasn't quite as straight forward as I hoped for. The Tailwind styling itself is not a problem, but it took me some time to figure out how to handle "click away" or "click outside" functionality and handling the escape key. On top of that I had to research how to do CSS transitions in React. Turns out that creators of Tailwind created a helpful transition library as React does not have the functionality built-in.

Doing a Google search for "react click away listener" didn't really help. A search on NPM for "react click outside" and "react click away" returned way too many more results than I needed. Sure, there are plenty of React libraries, but I felt that there should be a much simpler way of handling that.

Here is the Next.js (React + TypeScript) code I ended up with.

import Link from 'next/link';
import React, { useState, useRef, useEffect } from 'react';
import { Transition } from '@tailwindui/react';

const Menu = ({ user }) => {
  const [show, setShow] = useState(false);
  const container = useRef(null);

  useEffect(() => {
    const handleOutsideClick = (event: MouseEvent) => {
      if (!container.current.contains(event.target)) {
        if (!show) return;
        setShow(false);
      }
    };

    window.addEventListener('click', handleOutsideClick);
    return () => window.removeEventListener('click', handleOutsideClick);
  }, [show, container]);

  useEffect(() => {
    const handleEscape = (event: KeyboardEvent) => {
      if (!show) return;

      if (event.key === 'Escape') {
        setShow(false);
      }
    };

    document.addEventListener('keyup', handleEscape);
    return () => document.removeEventListener('keyup', handleEscape);
  }, [show]);

  return (
    <div ref={container} className="relative">
      <button
        className="menu focus:outline-none focus:shadow-solid "
        onClick={() => setShow(!show)}
      >
        <img
          className="w-10 h-10 rounded-full"
          src={user.picture}
          alt={user.name}
        />
      </button>

      <Transition
        show={show}
        enter="transition ease-out duration-100 transform"
        enterFrom="opacity-0 scale-95"
        enterTo="opacity-100 scale-100"
        leave="transition ease-in duration-75 transform"
        leaveFrom="opacity-100 scale-100"
        leaveTo="opacity-0 scale-95"
      >
        <div className="origin-top-right absolute right-0 w-48 py-2 mt-1 bg-gray-800 rounded shadow-md">
          <Link href="/profile">
            <a className="block px-4 py-2 hover:bg-green-500 hover:text-green-100">
              Profile
            </a>
          </Link>
          <Link href="/api/logout">
            <a className="block px-4 py-2 hover:bg-green-500 hover:text-green-100">
              Logout
            </a>
          </Link>
        </div>
      </Transition>
    </div>
  );
};

export default Menu;

When I was done with React implementation, I thought to myself of how I would implement the same menu in Svelte. So I took some time to port it to Svelte.

One of the many niceties about Svelte is that it has CSS transitions and animations built in. Here is my take on it.

<script>
  import { onMount } from 'svelte';
  import { scale } from 'svelte/transition';

  export let user;

  let show = false; // menu state
  let menu = null; // menu wrapper DOM reference

  onMount(() => {
    const handleOutsideClick = (event) => {
      if (show && !menu.contains(event.target)) {
        show = false;
      }
    };

    const handleEscape = (event) => {
      if (show && event.key === 'Escape') {
        show = false;
      }
    };

    // add events when element is added to the DOM
    document.addEventListener('click', handleOutsideClick, false);
    document.addEventListener('keyup', handleEscape, false);

    // remove events when element is removed from the DOM
    return () => {
      document.removeEventListener('click', handleOutsideClick, false);
      document.removeEventListener('keyup', handleEscape, false);
    };
  });
</script>

<div class="relative" bind:this={menu}>
  <div>
    <button
      on:click={() => (show = !show)}
      class="menu focus:outline-none focus:shadow-solid"
    >
      <img class="w-10 h-10 rounded-full" src={user.picture} alt={user.name} />
    </button>

    {#if show}
      <div
        in:scale={{ duration: 100, start: 0.95 }}
        out:scale={{ duration: 75, start: 0.95 }}
        class="origin-top-right absolute right-0 w-48 py-2 mt-1 bg-gray-800
          rounded shadow-md"
      >
        <a
          href="/profile"
          class="block px-4 py-2 hover:bg-green-500 hover:text-green-100"
        >Profile</a>
        <a
          href="/api/logout"
          class="block px-4 py-2 hover:bg-green-500 hover:text-green-100"
        >Logout</a>
      </div>
    {/if}
  </div>
</div>

Sure, the amount of code is little less in Svelte than in React, but what about the cognitive load? Which one is easier to read and understand? You be the judge.

Svelte, PostCSS and TypeScript with Svite bundler

Ilia Mikhailov — Sun, 06 Sep 2020 00:00:00 +0000

Svite has been on my radar for quite some time now and I finally found some time to play with it. I was surprised by the results.

I am on the quest to find the easiest, fastest and most flexible bundler for Svelte development. I think I just did.

My requirements

Testing different Svelte bundler setups is a weird hobby of mine. I get a kick out of connecting different plugins together, while trying to setup a smooth development workflow.

The requirements are pretty straight forward.

It must be fast
It must support Typescript
It must support PostCSS
It must produce small and efficient bundles
It must produce correct sourcemaps for debugging
It should support HMR (Hot Module Replacement)

My testing application

For my tests I created a simple Svelte app. Its functionality is simple. You press a button and it fetches a random Kanye West tweet from Kanye as a Service.

While simple, the application has some interesting parts.

Svelte components are written in Typescript. I want to see if transpiling and type checking works correctly for TS.
External Svelte library. Not all bundlers support libraries written in Svelte efficiently.
External library dependency. I want to see if a bundler supports tree shaking when bundling for production.
External Assets. It should be possible to import SVG, PNG, JSON and other external assets in our code.
PostCSS with TailwindCSS. A good bundler should make it easy to work with SASS and PostCSS.
Business components in Typescript. Typescript is here to stay. A good bundler should support it out-of-the-box.

Can Svite handle the pressure? Let's see!

Short notes on Svite

Svite is a pure Svelte bundler built by dominikg on top of Vite. I've already tested Vite with very impressive results, and since Svite is almost Vite, I expect the results to be equal or better.

What's great about Svite is that it has many different templates you can use when creating your app. Currently there are four:

minimal
routify-mdsvex
postcss-tailwind
svelte-preprocess-auto

It has also a few other useful options you can use too.

Creating a new project

Let's create an app by using postcss-tailwind template and adding TypeScript support.

$ npx svite create -pm pnpm -ts -t postcss-tailwind -sc svelte-svite-typescript
$ cd svelte-svite-typescript
$ npm run dev

That was easy! Let's look at the files it produced.

$ ls -1
index.html
node_modules
package.json
pnpm-lock.yaml
postcss.config.js
public
src
svelte.config.js
tailwind.config.js
tsconfig.json

And in the src directory you have these files.

$ ls src
App.svelte  index.css  index.ts

Nice! Almost the same files I had to write by hand when testing Vite.

Why almost? If you worked with Vite, you might notice that there is no vite.config.js. Because Svite has build in support for Svelte, there is no need to have one.

App.svelte

The file is small and with helpful comments in the right places.

<script lang="ts">
  const world = 'postcss'; // edit world and save to see hmr update
</script>

<style>
  h1 {
    color: orangered; /* change color an save to see hmr update */
    /* you can also use css nesting
    & .world {
      font-size: 2rem;
    }
    */
  }
  .world {
    @apply text-teal-500 italic; /*  here's some tailwind apply */
  }
</style>

<h1 class="border border-current rounded p-4 m-4">
  <!-- tailwind classes in svelte template -->
  Hello
  <span class="world">{world}</span>
</h1>

index.ts

The main file is clean and imports our base Tailwind file.

import App from './App.svelte';
import './index.css';

const app = new App({
  target: document.body,
});

export default app;

package.json

The package.json is clean and small.

{
  "name": "svelte-svite-typescript",
  "version": "0.0.0",
  "scripts": {
    "validate": "svelte-check && tsc --noEmit",
    "dev": "svite -ts",
    "build": "svite build -ts"
  },
  "dependencies": {
    "svelte": "3.24.1",
    "svelte-hmr": "0.10.2"
  },
  "devDependencies": {
    "@tsconfig/svelte": "^1.0.10",
    "postcss": "^7.0.32",
    "postcss-import": "^12.0.1",
    "postcss-load-config": "^2.1.0",
    "postcss-preset-env": "^6.7.0",
    "svelte-check": "^1.0.21",
    "svelte-preprocess": "4.1.1",
    "svite": "^0.6.0",
    "tailwindcss": "^1.7.3",
    "tslib": "^2.0.1",
    "typescript": "^3.9.7"
  }
}

A few dependencies are outdated, but we can update them with ncu -u && pnpm install command.

When starting everything works as advertised. Impressive!

Testing with Svite with my benchmark app

I copied the files in src directory from my Vite test setup and the app worked out of the box! I am not surprised since Svite is Vite abstracted.

Building

Let's compare Svite builds to Vite's.

# Svite

[write] dist/_assets/index.ab6f11f2.js 32.04kb, brotli: 9.50kb
[write] dist/_assets/style.45ed9e6c.css 8.10kb, brotli: 1.81kb
[write] dist/_assets/usa.fcca7834.svg 0.88kb
[write] dist/index.html 0.40kb, brotli: 0.16kb
Build completed in 8.37s.

# Vite

[write] dist/_assets/index.0729edbe.js 32.04kb, brotli: 9.50kb
[write] dist/_assets/style.393fa0c4.css 6.39kb, brotli: 1.67kb
[write] dist/_assets/usa.6aae1c82.svg 0.88kb
[write] dist/index.html 0.41kb, brotli: 0.16kb
Build completed in 5.16s.

The results are almost identical in terms of output and speed.

Results

Let's re-visit our list of requirements.

It must be fast. Check. Vite's cold starts and reloads feel superfast.
It must support Typescript. Check. Works out-of-the-box.
It must support PostCSS. Check. Works out-of-the-box.
It must produce small and efficient bundles. Check. Rollup is used for bundling.
It should be possible to import external Svelte libs. Check.
It must produce correct sourcemaps for debugging. So-so. Not very impressed, but ok.
It should support HMR (Hot Module Replacement). Check. Works great.

One annoying thing I found is that when you kill the dev server the whole app starts reloading itself.

Plugins and Libraries Mentioned

Conclusion

Svite is a nice little abstraction of Vitejs specifically tailored for Svelte development. It's fast, small and doesn't get in your way. Everything just works.

It feels thought though. For example, one thing I like is that Svite allows you to choose which package manager you want to use. It might be a small thing, but it's really nice that the author has thought of this.

If you feel you need to use some other Vite plugins that Svite doesn't offer, you can always create vite.config.js and wire them up there.

I didn't bother to setting up other useful scripts this time, like continuous linting, but if you are interested check out package.json in my Vite setup in the Github repo.

Svite might just be the easiest way to get your new Svelte project off the ground. The documentation is excellent and you have many different boilerplate templates to choose from. Just make sure to read the docs for all the possible options!

You can find the code here https://github.com/codechips/svelte-typescript-setups

I will definitely use Svite in the future!

Solid Sapper setup with PostCSS and Tailwind

Ilia Mikhailov — Sun, 06 Sep 2020 00:00:00 +0000

While it's straight forward to integrate PostCSS and Tailwind into plain Svelte projects, Sapper is a totally different beast. There are many moving parts. Rollup configuration is super complex, code is generated. It can be hard to grasp what's going on.

The Problem

I needed to integrate PostCSS together with Sapper. Meanwhile it's not so hard to integrate plain Tailwind CSS into Sapper, turns out integrating PostCSS together with TailwindCSS requires a little more work. After trying a few different approaches I finally landed on something that works for me.

Why PostCSS?

Plain CSS can take you far, but I often prefer to use Tailwind CSS. I find it really nice to work with declarative CSS instead of writing everything from scratch. I like Tailwind as it is, but I often use a few other PostCSS plugins too that help me work with Tailwind CSS more efficiently. Maybe a better word would be "augment" and not "help."

How Sapper manages CSS

Sapper has an internal router built-in. Which is helpful. The router intercepts all link clicks and fetches each page individually when you visit it. When you click on the link that leads to another page in your app, Sapper will fetch the page in the background and replace the content in your Sapper app.

It will actually put the content into the slot in the src/routes/_layout.svelte page. That's how it's setup in the official boilerplate at least.

Sapper injects the styles for different components and pages when you navigate between the pages. When you visit a page, Sapper will fetch that page and also inject the style for that page and for the components it uses into the head tag of the document.

Sapper and Svelte scope CSS classes defined in the components to the components themselves, reducing the risk of overriding the CSS.

To understand more read the blog post The zen of Just Writing CSS.

It's actually a really nice feature that you get out of the box in Svelte! You can see that by inspecting elements in the dev tools console. Each styled element will have a svelte-[hash] class defined on it.

The Solution

After wrestling with rollup-plugin-postcss for some time, I gave up and went with the simplest setup possible.

Instead of trying to integrate PostCSS into Rollup itself, I moved PostCSS processing outside of Rollup's pipeline. It's fast too, because the processing is done outside Rollup.

Here is how I did it.

Create a Sapper project

In order to fully understand what's needed, we will start from scratch by creating a standard Sapper project.

$ npx degit sveltejs/sapper-template#rollup sapper-with-postcss
$ cd sapper-with-postcss && npm i

You can now start the app by running npm run dev.

Setting up Tailwind

Let's add Tailwind and Tailwind's typography plugin that we will use to style the blog posts.

$ npm add -D tailwindcss @tailwindcss/typography
$ npx tailwindcss init

We now need to replace Tailwind's configuration file with this.

// tailwind.config.js

module.exports = {
  future: {
    removeDeprecatedGapUtilities: true,
  },
  experimental: {
    uniformColorPalette: true,
    extendedFontSizeScale: true,
    // currently Sapper dev server chokes on this
    // applyComplexClasses: true,
  },
  purge: {
    // needs to be set if we want to purge all unused
    // @tailwind/typography styles
    mode: 'all',
    content: ['./src/**/*.svelte', './src/**/*.html'],
  },
  theme: {
    container: {
      center: true,
    },
    extend: {},
  },
  variants: {},
  plugins: [require('@tailwindcss/typography')],
};

Next thing we need to do is to create Tailwind's base file. We will put it in src/assets folder, that you need to create first, and we will name it global.pcss.

We are using .pcss extension just to distinguish that it's a PostCSS file. It's not something you have to do. Plain .css extension works just a good. I like to distinguish PostCSS files from plain CSS.

/* global.pcss */

@tailwind base;

body {
  @apply bg-indigo-100;
}

@tailwind components;
@tailwind utilities;

Alright. Now that we are done with Tailwind configuration, let's wire it up into our PostCSS pipeline.

Setting up PostCSS with Tailwind

First things first. We need to install PostCSS cli and a few PostCSS plugins that we will use.

$ npm add -D postcss-cli
$ npm add -D autoprefixer postcss-import cssnano postcss-load-config postcss-preset-env

Next, we need to create PostCSS configuration file in the project's root folder.

// postcss.config.js

const tailwind = require('tailwindcss');
const autoprefixer = require('autoprefixer');
const cssnano = require('cssnano');
const postcssImport = require('postcss-import');
const presetEnv = require('postcss-preset-env')({
  features: {
    // enable nesting
    'nesting-rules': true,
  },
});

const plugins =
  process.env.NODE_ENV === 'production'
    ? [postcssImport, tailwind, presetEnv, cssnano]
    : [postcssImport, tailwind, presetEnv];

module.exports = { plugins };

Cool! We are almost there. Theoretically, we have everything we need. We just need to wire everything up.

PostCSS in Svelte files

Actually, I forgot something. We want to style our Svelte components with Tailwind and PostCSS too. In order for that to work we need to use the good ol' svelte-preprocess plugin.

$ npm add -D svelte-preprocess

Let's cheat a bit. We will create a svelte.config.js and setup the preprocessor there. Svelte config is needed for the editors to be able to work correctly. Syntax highlighting, intellisense and all those things.

We will later re-use the exported preprocessor in our Rollup config to keep things DRY.

// svelte.config.js

import autoProcess from 'svelte-preprocess';

export const preprocess = autoProcess({ postcss: true });

There are a few different ways to setup Svelte prepocessor, but I found this the most minimal. The reason it works is that we installed postcss-load-config plugin earlier. It will automatically load postcss.config.js file if it exists. No need to require it in our code!

Now that we have finished setting up the preprocessor, we need to import it in our Rollup config.

// rollup.config.js

import { preprocess } from './svelte.config';

// add preprocess to Svelte plugin in client section
svelte({
  dev,
  hydratable: true,
  emitCss: true,
  preprocess, // <-- add this
}),

// add preprocess to Svelte plugin in server section
svelte({
  generate: 'ssr',
  hydratable: true,
  dev,
  preprocess, // <-- add this
})

Phew! Everything is now configured correctly. Hopefully.

Adjust your NPM scripts

Last thing we need to do is to wire everything together. We will do it by changing the scripts section in our package.json.

"scripts": {
  "dev": "run-p watch:*",
  "watch:css": "postcss src/assets/global.pcss -o static/global.css -w",
  "watch:dev": "sapper dev",
  "build": "run-s build:css build:sapper",
  "build:css": "NODE_ENV=production postcss src/assets/global.pcss -o static/global.css",
  "build:sapper": "sapper build --legacy",
  "build:export": "sapper export --legacy",
  "export": "run-s build:css build:export",
  "start": "node __sapper__/build",
  "serve": "serve ___sapper__/export",
  "cy:run": "cypress run",
  "cy:open": "cypress open",
  "test": "run-p --race dev cy:run"
}

This requires some explanation. You can see that we have a watch:css script. What it does is replaces Sappers static/global.css with our Tailwind base file. We also need to explicitly set NODE_ENV to "production" in build:css since we are doing our PostCSS processing outside Sapper. It's needed by Tailwind in order to purge unused CSS styles from its base file.

Be careful not to set NODE_ENV to production in the Sapper build and export scripts. If you do, and you set any :global styles in your components, they will be purged leading to missing styles.

Oh, just another tip. If you what to use a background image in you CSS put it in the static folder. You can then use it your CSS like this.

.hero {
  background-image(image.png);
}

Test-driving the new setup

To check that Tailwind and PostCSS works in Svelte components, replace your src/routes/index.svelte with this code.

<!-- index.svelte -->

<style lang="postcss">
  .btn {
    @apply bg-red-500 text-red-100 uppercase tracking-wide font-semibold
      text-4xl px-4 py-3 shadow-lg rounded;
  }
</style>

<svelte:head>
  <title>Sapper project template</title>
</svelte:head>

<div class="space-y-10 text-center">
  <h1 class="text-7xl uppercase font-bold">Great success!</h1>
  <button class="btn">DO NOT PRESS THIS BUTTON!</button>
</div>

You can see that we set lang="postcss" in the style tag. That's not something that is required, PostCSS will still be processed. It's only so that editor understands it's dealing with PostCSS.

To see Tailwind's typography plugin in action change src/routes/blog/[slug].svelte to the code below.

<script context="module">
  export async function preload({ params, query }) {
    const res = await this.fetch(`blog/${params.slug}.json`);
    const data = await res.json();

    if (res.status === 200) {
      return { post: data };
    } else {
      this.error(res.status, data.message);
    }
  }
</script>

<script>
  export let post;
</script>

<svelte:head>
  <title>{post.title}</title>
</svelte:head>

<!-- prose is a class from Tailwind typography plugin -->
<div class='prose prose-lg'>
  <h1>{post.title}</h1>

  {@html post.html}
</div>

And ... we are finally done!

Demo

Below you can see the setup in action running on Vercel. Make sure to check out individual blog posts to see Tailwind's typography plugin in action.

Oh, and please don't press that button. Don't say I didn't warn you!

Live demo: https://sapper-with-postcss-and-tailwind.vercel.app

Mentioned and used plugins

Conclusion

Implementing PostCSS in Sapper becomes clear when you understand how Sapper deals with CSS files.

We set up two separate PostCSS pipelines in our example app. First is processing Sapper's global CSS file. Second is replacing Sapper's component styling with PostCSS. We didn't actually change the way Sapper handles and serves CSS files, we only replaced it with PostCSS. Maybe "augmented" is a better word.

You can find the full code here github.com/codechips/sapper-with-postcss-and-tailwind.

Now go and create some beautifully styled apps!