DEV Community: Josef Aidt

Theming in Svelte with CSS Variables

Josef Aidt — Mon, 23 Mar 2020 19:37:06 +0000

In React there are numerous theming solutions to choose from; styled-components, Emotion, styled-system, theme-ui – the list goes on. But in Svelte, a framework that feels like you have a front-row spot on The Platform™, those kinds of solutions don't exist. When I cracked open my brand new Svelte project I knew I wanted I knew I wanted to allow visitors to set (and persist) their preferred theme so they don't have to feel the pain of light mode if they don't want to.

Enter svelte-themer, a solution I originally implemented in as part of my website, but something I recently turned into an npm package.

What is Svelte?

Svelte has been labeled as the "new framework on the block", touted for being effective and efficient for building web applications quickly. Compared to the big players in the game — React, Angular, and Vue — it certainly brings a unique approach to the build process while also component-based.

First of all, it feels very close to the platform meaning fewer frills or abstractions than a framework like React; the platform being the web (plain HTML, CSS, JavaScript). It feels like what natively supported web modules should feel like. Svelte has a few frills; check out this small snippet:

<!-- src/components/Heading.svelte -->
<script>
  export let name = 'World'
</script>

<h1>Hello {name}</h1>

<style>
  h1 {
    color: green;
  }
</style>

That's it for a stateful heading component. There's a few things going on here:

<!-- src/components/Heading.svelte -->
<script>
  // define a prop, `name`, (just like React)
  // give it a default value of `World`
  export let name = 'World'
</script>

<!-- use curly braces to refer to `name` value -->
<h1>Hello {name}</h1>

<style>
  /* scoped style */
  h1 {
    color: green;
  }
</style>

Now when we want to use it, it'll feel like using any other React component:

<!-- src/App.svelte -->
<script>
  import Heading from './components/Heading.svelte'
</script>

<main>
  <Heading name="Hansel" />
</main>

For more information I highly recommend checking out the tutorial on Svelte's site.

Theming

Thinking about how we want to shape the theme structure we immediately think of two things:

Set/Collection of theme objects
Toggle function

This means we'll need a way to store the toggle function, provide it to the rest of our app, and consume it somewhere within the app.

Here this component will be a button. If you're coming from React this may seem all too familiar, and it is. We're going to be using two of Svelte's features:

context: framework API to provide & consume throughout the app with the help of a wrapper component
writable stores: store data (themes, current theme)

Svelte's tutorial demonstrates their writable stores by separating the store into its own JavaScript file. This would be preferable if we were to later import the theme values to use in a component's <script> section and use the methods that come along with writable stores such as .set() and .update(), however the colors should not change and the current value will be toggled from the same file. Therefore we're going to include the store right in our context component.

The Context Component

<!-- src/ThemeContext.svelte -->
<script>
  import { setContext, onMount } from 'svelte'
  import { writable } from 'svelte/store'
  import { themes as _themes } from './themes.js'
</script>

<slot>
  <!-- content will go here -->
</slot>

Let's take a quick look at these imports:

setContext: allows us to set a context (key/value), here this will be theme
onMount: function that runs on component mount
writable: function to set up a writable data store
_themes: our themes!

After the script block you'll notice the <slot> tag, and this is special to Svelte. Coming from React think of this as props.children; this is where the nested components will go.

Presets

A quick look at the preset colors for this demo.

// src/themes.js
export const themes = [
  {
    name: 'light',
    colors: {
      text: '#282230',
      background: '#f1f1f1',
    },
  },
  {
    name: 'dark',
    colors: {
      text: '#f1f1f1',
      background: '#27323a',
    },
  },
]

Writable Store

<!-- src/ThemeContext.svelte -->
<script>
  import { setContext, onMount } from 'svelte'
  import { writable } from 'svelte/store'
  import { themes as _themes } from './themes.js'
  // expose props for customization and set default values
  export let themes = [..._themes]
  // set state of current theme's name
  let _current = themes[0].name

  // utility to get current theme from name
  const getCurrentTheme = name => themes.find(h => h.name === name)
  // set up Theme store, holding current theme object
  const Theme = writable(getCurrentTheme(_current))
</script>

<slot>
  <!-- content will go here -->
</slot>

It's important to note that _current is prefixed with an underscore as it will be a value we use internally to hold the current theme's name. Similarly with _themes, they are used to populate our initial themes state. Since we'll be including the current theme's object to our context, it is unnecessary to expose.

setContext

<!-- src/ThemeContext.svelte -->
<script>
  import { setContext, onMount } from 'svelte'
  import { writable } from 'svelte/store'
  import { themes as _themes } from './themes.js'
  // expose props for customization and set default values
  export let themes = [..._themes]
  // set state of current theme's name
  let _current = themes[0].name

  // utility to get current theme from name
  const getCurrentTheme = name => themes.find(h => h.name === name)
  // set up Theme store, holding current theme object
  const Theme = writable(getCurrentTheme(_current))

  setContext('theme', {
    // provide Theme store through context
    theme: Theme,
    toggle: () => {
      // update internal state
      let _currentIndex = themes.findIndex(h => h.name === _current)
      _current = themes[_currentIndex === themes.length - 1 ? 0 : (_currentIndex += 1)].name
      // update Theme store
      Theme.update(t => ({ ...t, ...getCurrentTheme(_current) }))
    },
  })
</script>

<slot>
  <!-- content will go here -->
</slot>

Now we have the context theme set up, all we have to do is wrap the App component and it will be accessible through the use of:

<!-- src/MyComponent.svelte -->
<script>
  import { getContext } from 'svelte'
  let theme = getContext('theme')
</script>

By doing so, providing access to the Theme store and our theme toggle() function.

Consuming Theme Colors - CSS Variables

Since Svelte feels close to The Platform™️ we'll leverage CSS Variables. In regards to the styled implementations in React, we will ignore the need for importing the current theme and interpolating values to CSS strings. It's fast, available everywhere, and pretty quick to set up. Let's take a look:

<!-- src/ThemeContext.svelte -->
<script>
  import { setContext, onMount } from 'svelte'
  import { writable } from 'svelte/store'
  import { themes as _themes } from './themes.js'
  // expose props for customization and set default values
  export let themes = [..._themes]
  // set state of current theme's name
  let _current = themes[0].name

  // utility to get current theme from name
  const getCurrentTheme = name => themes.find(h => h.name === name)
  // set up Theme store, holding current theme object
  const Theme = writable(getCurrentTheme(_current))

  setContext('theme', {
    // providing Theme store through context makes store readonly
    theme: Theme,
    toggle: () => {
      // update internal state
      let _currentIndex = themes.findIndex(h => h.name === _current)
      _current = themes[_currentIndex === themes.length - 1 ? 0 : (_currentIndex += 1)].name
      // update Theme store
      Theme.update(t => ({ ...t, ...getCurrentTheme(_current) }))
      setRootColors(getCurrentTheme(_current))
    },
  })

  onMount(() => {
    // set CSS vars on mount
    setRootColors(getCurrentTheme(_current))
  })

  // sets CSS vars for easy use in components
  // ex: var(--theme-background)
  const setRootColors = theme => {
    for (let [prop, color] of Object.entries(theme.colors)) {
      let varString = `--theme-${prop}`
      document.documentElement.style.setProperty(varString, color)
    }
    document.documentElement.style.setProperty('--theme-name', theme.name)
  }
</script>

<slot>
  <!-- content will go here -->
</slot>

Finally we see onMount in action, setting our theme colors when the context component mounts, by doing so exposing the current theme as CSS variables following the nomenclature --theme-prop where prop is the name of the theme key, like text or background.

Toggle Button

For the button toggle we'll create another component, ThemeToggle.svelte:

<!-- src/ThemeToggle.svelte -->
<script>
  import { getContext } from 'svelte'
  const { theme, toggle } = getContext('theme')
</script>

<button on:click={toggle}>{$theme.name}</button>

And we're ready to put it all together! We've got our theme context, a toggle button, and presets set up. For the final measure I'll leave it up to you to apply the theme colors using the new CSS variables.

Hint

main {
  background-color: var(--theme-background);
  color: var(--theme-text);
}

Theming Result

CodeSandbox

Moving Forward

Themes are fun, but what about when a user chooses something other than the default set on mount? Try extending this demo by applying persisted theme choice with localStorage!

Conclusion

Svelte definitely brings a unique approach to building modern web applications. For a slightly more comprehensive codebase be sure to check out svelte-themer.

If you're interested in more Svelte goodies and opinions on web development or food check me out on Twitter @josefaidt.

Using ZEIT's Now as a Reverse Proxy

Josef Aidt — Fri, 08 Nov 2019 15:17:27 +0000

For a while now I've wanted to host a simple website that acted as a pretty front-end for my Plex server and the cluster of applications I use alongside Plex to enhance the experience. Applications like a request service (Ombi) and a metrics service (Tautulli). Originally I learned and built an NGINX-based container to use as the reverse proxy, though this was until I realized my new Linksys router reserved port 80 for Linksys SmartConnect. Ever since then I just kind of sat on the idea.

Over the course of a few days I scoured the web for references to ZEIT's Now platform looking for ways to use the routing capabilities as a proxy, and ended up with having my epiphany right there at their documentation. My question was could this be done? Using the platform to proxy requests to these exposed applications running at my house, just like I would have had with NGINX? Short answer, yes.

ZEIT Now

First off, what is ZEIT Now? When you type in "zeit now" on Google, the first link you'll see has the tagline "world class static hosting, All-in-one solution for static & JAMstack deployment for performance-obsessed teams." The keyword here is static, meaning you cannot run an always-on Node.js server, like Express.

Overall, ZEIT Now is a serverless platform that can serve a number of types of files using builders, thus being able to host a static site comprised of HTML, CSS, and JavaScript files, as well as defining routes to serve such files or - in our case - proxy to another application on the same domain.

Given our previous example we could run an Express application that proxies requests in the same fashion we're looking to accomplish with this guide locally or in a container on a server, however given the nature of ZEIT's Now v2 we'll need to get down to the platform and use its capabilities to our advantage.

The Pain Point

Let's say we have the following application details:

Application	Port	Location
Plex	32400	home
Request (Ombi)	9001	home
Metrics (Tautulli)	9002	home
existing front-end(?)	80 & 443	ZEIT Now
custom domain	-	Google Domains

With a home (external) IP of 50.50.500.192 (disclaimer: this IP is fake and for demonstration purposes). We then set up our DNS via Google Domains with an A record for @ pointing at our home IP.

Now if we navigate out to myplexdomain.com:9001 we should see Ombi running. Same with Tautulli but with specifying port 9002. Great, right? Everything works as intended. But what if we as Plex server owners could give out this snazzy new domain without having our users specifying those ports? Users shouldn't have to remember or bookmark the address with the ports. Plus it's easier to remember something like myplexdomain.com/request than the port, right?

In comes ZEIT Now.

Pre-Requisites

a running Plex server
applications running on a few exposed ports
a custom domain (myplexdomain.com)
ZEIT Now account

That's about it. I won't go over how to set these apps up or forward ports on your router, but assuming you have this done already and simply want to create a website to proxy the requests then I hope this article serves you well.

Implementation

Now that we have all of these apps running, accessible from an external address, etc, let's go over setting up our frontend.

Add Base Route to Applications

Before we get started, there is another pre-requisite to ensure application assets (like stylesheets) will be served over the proper prefix (ex: request/) rather than from the root. Edit Ombi and Tautulli to have the base routes of request and metrics respectively.

Change NameServers to ZEIT Now

Next we'll need to add our new domain to ZEIT Now and point the nameservers to that of ZEIT. Something like this:

After a few hours or so the ZEIT Now domains panel should show that the domain is now verified. Great, we'll want to use the Now CLI to set up a new record.

Flip over to your terminal of choice and ensure you have the latest Now CLI installed with yarn global add now@next.

Remember our home IP? We'll need that to point the subdomain of home to that IP with now dns add myplexdomain.com home A 50.50.500.192. Once the change has propagated we should be able to access our applications by navigating to home.myplexdomain.com:9001/request. Fantastic.

Our ZEIT Now Project

Ignoring the frontend for now, let's take a look at setting up the routing for our new Now project.

# create a new directory for the project
mkdir now-myplexdomain

# create the new Node project
cd now-myplexdomain
yarn init -y
touch now.json

# open with VSCode
code now-myplexdomain

It is important to note that we will specify an empty build command since we don't need to actually build anything for the Now deployment. Pop open your package.json file and copy the following:

{
  "scripts": {
    "build": "echo 'No build required, skipping...'"
  }
}

Now we're ready to start the routing!

ZEIT Now Routing

The routing capabilities with ZEIT Now are ridiculously powerful, and the reason I went with this platform. With our fresh now.json file, let's make a few edits:

{
  "public": false,
  "routes": [
    {
      "src": "/request/(.*)",
      "dest": "http://home.myplexdomain.com:9001/request/$1"
    },
    { "src": "/metrics/(.*)", "dest": "http://home.myplexdomain.com:9002/metrics/$1" }
  ]
}

A few important things to note here.

"public": false - this is needed for the Now deployment to show this project is not public. I suppose we could leave this open, however to tighten our security and the proxied requests, I leave this set to false.
"src": "/request/(.*)" - little RegEx to pass subsequent requests of all file types to our destination
"dest": "http://home.myplexdomain.com:9001/request/$1" - the $1 is there to embed the capture group, passing the subsequent requests to appropriate target destination
when hitting /request and not /request/ the request will fail. To fix this we can add a redirect

Redirects

To fix the last item in the routing notes, let's set up a redirect:

{
  "public": false,
  "routes": [
    {
      "src": "/request/(.*)",
      "dest": "http://home.myplexdomain.com:9001/request/$1"
    },
    { "src": "/request", "status": 301, "headers": { "Location": "/request/" } },
    { "src": "/metrics/(.*)", "dest": "http://home.myplexdomain.com:9002/metrics/$1" },
    { "src": "/metric", "status": 301, "headers": { "Location": "/metrics/" } }
  ]
}

Now if we attempt to hit /metrics without the trailing slash, we should expect the behavior of redirecting the user to /metrics/. With these redirects we can also set up a sleek path to launch the Plex web application, which is external to our site.

{
  "public": false,
  "routes": [
    {
      "src": "/request/(.*)",
      "dest": "http://home.myplexdomain.com:9001/request/$1"
    },
    { "src": "/request", "status": 301, "headers": { "Location": "/request/login" } },
    { "src": "/metrics/(.*)", "dest": "http://home.myplexdomain.com:9002/metrics/$1" },
    { "src": "/metric", "status": 301, "headers": { "Location": "/metrics/" } },
    { "src": "/launch", "status": 301, "headers": { "Location": "https://app.plex.tv/" } }
  ]
}

With this update we can set up a /launch path in our frontend to easily send the user to Plex. You may also notice I added a /login to the request path, and this is because Ombi will not properly redirect. Instead we must force the user straight to the login page, which will then be redirected into the app's homepage if the auth token is present.

Front-end

At this point, the frontend is trivial, though serving the content may not be. No worries, we'll take a quick look at a simple frontend implementation. Create a new file, public/index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>myplexdomain</title>
  </head>
  <body>
    <main>
      <ul>
        <li><a href="/request">Request</a></li>
        <li><a href="/metrics">Metrics</a></li>
        <li><a href="/launch">Launch Plex</a></li>
      </ul>
    </main>
  </body>
</html>

It's really quite bare, however for this proof-of-concept implementation I'll leave the styling up to your own creativity. But now we need a root route and assign the appropriate builder for this new file, so let's pop back over to our now.json file.

{
  "public": false,
  "builds": [{ "src": "/public/**", "use": "@now/static" }],
  "routes": [
    { "src": "/", "dest": "/public/index.html" },
    {
      "src": "/request/(.*)",
      "dest": "http://home.myplexdomain.com:9001/request/$1"
    },
    { "src": "/request", "status": 301, "headers": { "Location": "/request/login" } },
    { "src": "/metrics/(.*)", "dest": "http://home.myplexdomain.com:9002/metrics/$1" },
    { "src": "/metric", "status": 301, "headers": { "Location": "/metrics/" } },
    { "src": "/launch", "status": 301, "headers": { "Location": "https://app.plex.tv/" } }
  ]
}

You'll notice the builder is using @now/static to serve static files from the public directory as well as a route at the root to serve our newly created HTML file. And that's it! If we run now dev we should see everything is functioning as intended.

Deploy

The fun part, we've made it! Let's get this thing on the web.

# deploy to ZEIT Now, follow the prompts for naming
now

# once confirmed functional, deploy to production (to link the domain)
now --prod

Congratulations, you now have a functional frontend for your fancy Plex apps. Slap some CSS in there and go crazy.

Final Thoughts

Learning ZEIT Now to this extent has been a rewarding journey. I've used the platform in the past, though this effort took my appreciation to a whole new level. I thought I wouldn't be able to have a frontend for apps running at my home due to my router issue, though I am incredibly glad I was able to accomplish this with ZEIT Now.

Enhancing Your Workflow With Fish Shell Functions

Josef Aidt — Fri, 01 Mar 2019 20:05:11 +0000

First and foremost, this is my first post to dev.to! I've never really blogged in the past, but if you'd like to check out my other (3) blog posts you can head on over to josefaidt.me/blog.

The tooling surrounding the JavaScript community is uncanny. There are so many useful tools out in the wild such as Webpack, Rollup, create-react-app, Gatsby, VSCode extensions, and let's not forget npm & Yarn! Despite this I feel we often overlook our most important tool, the command line.

Though daunting at first, the command line has proven its reliability and operability time after time with utilities like Homebrew and Git. Even the lower-level, out-of-the-box utilities like cat and grep are incredibly useful. If you're not the type of person that prefers point-and-click operations to do something as monotonous copying a file or peeking into a file's contents then you may already know the value bash/fish functions provide to drastically improve your existing workflow. But utilities don't have to be intense to be useful in the smallest regards.

Typing commands such as yarn workspace someWorkspace run someScript can get tedious when you're in the middle of debugging an application. Or even specifying a configuration file in ESLint using eslint --config ~/.config/.eslintrc.js someDirectory if you're using a global config file. Some commands or words can be easily fumbled when typing (e.g. "components" and "workspace"). This is where functions come in to play.

Fish Functions

Here we will be exploring functions in fish shell, specifically how we can use its functions to shorten our everyday commands such as the two noted above. The syntax is different compared to traditional bash aliases, but I hope to get you up and running in no time by guiding you through a few examples.

Let's start with yarn workspaces by using an alias that is as fluid to type as it is short. Open your Fish configuration file via code ~/.config/fish/config.fish and input the following:

function ywrs
  command yarn workspaces $argv
end

That's it! You have just created your first function! Let's break this down:

function: declaration keyword
ywrs: our alias, this is what we will be able to type in our terminal
command yarn workspaces $argv
- command: keyword needed to tell the shell to "execute" the following command, just as how you would normally type into the terminal
- yarn workspaces: the command we are wrapping
- $argv: pass the remaining arguments to the defined command
- ywrs info will thus execute yarn workspaces info

To test out your new function you will need to reload the fish configuration by reevaluating the config.fish file (this is also done when a new shell session is created): source ~/.config/fish/config.fish.

Now that you've got your feet wet, let's try a few more examples.

Yarn Workspace

function ywr
  command yarn workspace $argv
end

Similar to the initial example, this will allow us to easily execute commands in a workspace via a keyword that is both short and easy to type.

ESLint

function eslint
  command eslint --config ~/.eslintrc.js $argv
end

Here we are extending the existing, global eslint command by specifying a configuration file that can now be used throughout your projects without setting up a project-level ESLint dotfile. For additional learning regarding global ESLint and VSCode, check out my other blog post.

An Intense Example

The ESLint example above allows you to use the eslint command with a single configuration file, but what about automating the project-level install? Below we will discover how we can leverage functions, internal functions, and a bit of bash logic to install all of our ESLint dependencies and copy our global configuration file to the working directory.

function yawn
    if test (count $argv) -lt 1; or test $argv[1] = "--help"
        printf "Don't yawn too loud now, I need a package name"
    else if test (count $argv) -eq 1
        switch $argv[1]
            case 'eslint'
                _install_eslint
            case '*'
                echo "Doesn't look like I have that package, try again."
        end
    else
        echo $argv
    end
end

function _install_eslint
    yarn add -D \
        eslint babel-eslint eslint-loader \
        prettier eslint-config-prettier eslint-plugin-prettier \
        eslint-config-standard eslint-plugin-standard \
        eslint-plugin-node \
        eslint-plugin-jsx-a11y \
        eslint-plugin-promise \
        eslint-plugin-import \
        eslint-plugin-react \
    ;and cp ~/.config/.eslintrc.js .
end

Though we won't dive too deep into this example, let's briefly go over what value this it brings to the workflow:

function yawn...: high-level alias that acts as a cli utility to route a subcommand (passed as an argument) and call its respective internal alias
function _install_eslint...: internal alias that will be called from yawn given the input is yawn eslint.
- installs ESLint dependencies
- copies global ESLint config file
- NOTE: often times commands used internally (not directly called by the user) will be prepended with an underscore, here we utilize this nomenclature to make our config.fish file more readable

With these new functions you are now able to dive into a new project and call yawn eslint to set up ESLint. Personally I use this all the time and love to automate monotonous tasks just like this example.

Final Thoughts

So far we've covered:

Fish functions
Editing and using the Fish dotfile: config.fish
Reloading the dotfile
Using functions to shorten commands
Using functions to extend commands
Using functions to automate tasks

I hope I was able to convince you to start using this functionality, whether you use the examples provided or by creating your own. Speaking of, in the last example I provided the skeleton to add more subcommands to the yawn function, try setting up your own internal function that helps automate the tedious aspects of your workflow! I'd love to hear how Fish functions have enhanced your workflow, Tweet @garlicbred with your story!

DEV Community: Josef Aidt

Theming in Svelte with CSS Variables

What is Svelte?

Theming

The Context Component

Presets

Writable Store

setContext

Consuming Theme Colors - CSS Variables

Toggle Button

Theming Result

Moving Forward

Conclusion

Using ZEIT's Now as a Reverse Proxy

ZEIT Now

The Pain Point

Pre-Requisites

Implementation

Add Base Route to Applications

Change NameServers to ZEIT Now

Our ZEIT Now Project

ZEIT Now Routing

Redirects

Front-end

Deploy

Final Thoughts

Enhancing Your Workflow With Fish Shell Functions

Fish Functions

Yarn Workspace

ESLint

An Intense Example

Final Thoughts

Resources