DEV Community: Dan Strandberg

"Drawing" with box-shadow

Dan Strandberg — Fri, 05 Jun 2020 22:35:49 +0000

I like to share one "trick" or technique that I really like, it's one of those things that's good to have in the tool belt and I've found myself using it pretty often over the years.

The box-shadow property

When you think of box shadow, it's easy to only think of it as shadows on boxes, but it can do more. You can actually use it to draw in a sense.

Here we have two boxes, one is obviously using a box shadow, but the other one is as well.

You can "draw" on the outside:

.el {
    box-shadow: 
        0 0 0 3px red,
        0 0 0 8px green,
        0 0 0 10px blue;
}

or "draw" on the inside:

.el {
    box-shadow: 
        inset 0 0 0 3px red,
        inset 0 0 0 8px green,
        inset 0 0 0 10px blue;
}

You apply multiple box shadows to draw lines that overlap. So the above would result in a "border" of 3px red, 5px green, 2px blue and in this lies the power.

You can get really creative with this technique.

Like the tablet above, it has two HTML elements with psuedo ::before and ::after elements. Most of the layers are box-shadows. 🙂

Visibility detection using Svelte

Dan Strandberg — Fri, 06 Mar 2020 07:35:01 +0000

I've been playing around with Svelte lately and I really enjoy it. If you haven't heard of Svelte before I highly recommend watching Rethinking reactivity from the author Rich Harris.

Svelte compiles into imperative and performant JavaScript, it uses no Virtual DOM diffing like many other frameworks. The compilation step will strip out features and styles that aren't used so it won't get into the final bundle. But the best thing about Svelte could be the expressiveness of the framework 😍.

TLDR Visibility detection

Lazy load: https://svelte.dev/repl/97df8ddcd07a434890ffb38ff8051291?version=3.19.1

A little crazy: https://svelte.dev/repl/6d5c36ae0d2647298f0485b00b9dbfa9?version=3.19.1

With transitions: https://svelte.dev/repl/7bc94b49825f47728444fe8b0ed943cc?version=3.19.2

Project setup

Some of you might already be familiar with Svelte, some might not, I will try explain as much as I can so it's easy to follow along.

To create a new Svelte project:



npx degit sveltejs/template my-svelte-project

This uses the default sveltejs template to generate the project files. You can change to folder name if you like. Our new project should look something like this:



├── README.md
├── package.json
├── public
│   ├── favicon.png
│   ├── global.css
│   └── index.html
├── rollup.config.js
└── src
    ├── App.svelte
    └── main.js

Now within the project folder we should start by installing all the dependencies.



npm install

⸨       ░░░░░░░░░░░⸩⸩ :. extract:svelte: ...

With our dependencies installed we can start our dev-server.



npm run dev

Your application is ready~! 🚀

- Local:      http://localhost:5000

Now we are up and running, you can visit localhost:5000 and you'll see a simple Hello World application.

What we are going to build

It's not uncommon to defer loading content until it's visible to the user, often referred to as lazy loading. To be able to lazy load we need a way to detect when elements are in screen.

Maybe we can aim to build a general purpose Visibility detector and through it see how Svelte can interact with web api's like the InterSectionObserver. Maybe we can make it reusable and flexible enough for different uses cases including but not limited to lazy loading.

Let's create a new file in the src directory called Visibility.svelte that will hold the code for our Visibility detection.



:
└── src
    ├── Visibility.svelte <-- NEW FILE
    ├── App.svelte
    └── main.js

Our Visibility component will make use of the IntersectionObserver and through it we will register an element and detect when it intersects with the viewport of our document.

It can take a threshold option and with it we can configure which parts in the intersection we are interested in.

Say we provide an array of [0, 0.5, 1] for the threshold, this would result in events when it starts to intersect (0), when 50% of our element is visible (0,5) and when the element is completely visible (1).

Code walkthrough

In Svelte the JavaScript is put within a <script> tag. Most of the js code will work just as expected but there's also some Svelte specific functionality which I'll try to explain.

This component doesn't have any styling, if it did it would be put within a <style> tag and be scoped to the component.

The HTML elements are put in the document just as you would in a regular index.html file.

Visbility.svelte



<script>
    import {onMount} from 'svelte';

    export let top = 0;
    export let bottom = 0;
    export let left = 0;
    export let right = 0;

    export let steps = 100;

    let element;
    let percent;
    let observer;
    let unobserve = () => {};
    let intersectionObserverSupport = false;

    function intersectPercent(entries) {
        entries.forEach(entry => {
            percent = Math.round(Math.ceil(entry.intersectionRatio * 100));
        })
    }

    function stepsToThreshold(steps) {
        return [...Array(steps).keys()].map(n => n / steps)
    }

    onMount(() => {
        intersectionObserverSupport =
                'IntersectionObserver' in window &&
                'IntersectionObserverEntry' in window &&
                'intersectionRatio' in window.IntersectionObserverEntry.prototype;

        const options = {
            rootMargin: `${top}px ${right}px ${bottom}px ${left}px`,
            threshold: stepsToThreshold(steps)
        };

        if (intersectionObserverSupport) {
            observer = new IntersectionObserver(intersectPercent, options);
            observer.observe(element);
            unobserve = () => observer.unobserve(element);
        }

        return unobserve;
    });
</script>

<div bind:this={element}>
    <slot {percent} {unobserve}/>
</div>

In Svelte whenever we want to expose properties in our component we use export let <property name> and if we assign it a value it will act as the default if it's not passed in.

The first collection of properties we expose is top, left, bottom and right. These are offset values for the intersection container, they adjust the placement of the "box" that our elements will pass through.

The next property we have is steps, this is just a number we are going to use to create thresholds, if we set it to 100 it would create [0.01, 0.02 ... 0.98, 0.99, 1]. If we have 100 steps then events will be emitted whenever the visibility changes by one percent.

Elements we want to observe needs to be in the DOM, so we import the life cycle method onMountfrom Svelte. It takes a callback that's invoked when the DOM is ready. And if we return a function from the onMount callback it gets invoked when the component is destroyed.

We return the unobserve function to ensure it is called at end of the component life cycle. Now before we continue I would like to show how this component would be used.



import Visibility from `Visibility.svelte`

<Visibility steps={100} let:percent let:unobserve}>
  {#if percent > 50}
    <h1 use:unobserve>Hello world</h1>
  {/if}
</Visibility>
```

In the code above we has access to `percent` and `unobserve` (I'll come back to how this works in a moment). The `use:unobserve` is called an action in Svelte, the action will be invoked when the if statement is true, the `<h1>` gets created and we unobserve the container that wraps our content.


```html
<div bind:this={element}>
 <slot {percent} {unobserve} />
</div>
```

Behind the scenes this is wired up with a div using `bind:this={element}` directive. This allow us to get a reference to the DOM element and bind it to the variable inside the brackets.

The reason we use a wrapping div is because the InterSectionObserver needs a DOM element and we're not allowed to use directives on the slot itself.

The slot item will take on the content we pass into the `<Visibility>` tag. The `{percent}` and `{unregister}` is slot properties, this is why we can access them in the parent through `let:percent` and `let:unregister`.

That's all we need for flexible lazy loading. Now we have steps set to 100, it's not required though, we could use `steps={2}` to get `[0, 0.5]` and it would still work.

The example above is very simple and might be a little tricky to see what's going on. We would need to put the content off screen and maybe visualize the precent somehow. 

We can use the [Online REPL](https://svelte.dev/repl/). Here's one example that lazy loads an image once the visibility hits 70 percent: https://svelte.dev/repl/97df8ddcd07a434890ffb38ff8051291?version=3.19.1

And here's the code, the reload function is just for convenience so we can easily try it out more than once. The whole `<Visibility>` block will be recreated when hitting reload. 


```html
<script>
    import Visibility from './Visibility.svelte'

    let show = true;

    function reload() {
        show = false;
        setTimeout(() => show = true, 100)
    }
</script>

<style>
    main {
        text-align: center;
    }

    h1 {
        letter-spacing: .1rem;
        margin-bottom: 100vh;
    }

    section {
        display: flex;
        align-items: center;
        justify-content: center;
        margin-bottom: 10rem;
        padding: 1rem;
        position: relative;
        box-shadow: 0 0 10px -5px black;
        height: 300px;
    }

    img {
        height: 300px;
        width: 300px;
    }

    .top-left, .top-right, .bottom-left, .bottom-right {
        position: absolute;
        background: yellow;
        padding: .5rem;
        font-size: .8rem;
        font-weight: 700;
    }

    .top-left {
        top: 0;
        left: 0;
    }

    .top-right {
        top: 0;
        right: 0;
    }

    .bottom-left {
        bottom: 0;
        left: 0;
    }

    .bottom-right {
        bottom: 0;
        right: 0;
    }
</style>

<main>
    <button on:click={reload}>Reload</button>
    <h1>Scroll down</h1>

    {#if show}
        <Visibility steps={100} let:percent let:unobserve>
            <section>
                <span class="top-left">{percent}%</span>
                <span class="top-right">{percent}%</span>
                <span class="bottom-left">{percent}%</span>
                <span class="bottom-right">{percent}%</span>


                {#if percent > 70}
                    <img alt="Robot"
                         use:unobserve
                         src="https://robohash.org/svelte-is-awesome.png">
                {/if}
            </section>
        </Visibility>
    {/if}
</main>

```

## Let's get a little crazy  
We could keep the observer running and hook into the percent values we get and use it to create some new styles: https://svelte.dev/repl/6d5c36ae0d2647298f0485b00b9dbfa9?version=3.19.1


```html
<script>
    import Visibility from './Visibility.svelte'

    function getStyle(percent) {
        return `
            opacity: ${percent/100};
            transform: rotate(${percent * 3.6}deg) scale(${percent/100});
        `
    }
</script>

<!-- styles here, omitted for brevity -->

<main>
    <h1>Scroll down</h1>

    <Visibility steps={100} let:percent let:unobserve>
        <section style="{getStyle(percent)}">
            <span class="top-left">{percent}%</span>
            <span class="top-right">{percent}%</span>
            <span class="bottom-left">{percent}%</span>
            <span class="bottom-right">{percent}%</span>

            <figure>
                <img alt="Robot"
                     src="https://robohash.org/svelte-is-awesome.png">
            </figure>
        </section>
    </Visibility>
</main>
```

Here we modify the DOM with new styles, but we could also make use of svelte transitions and I encourage you to. These will get translated to css animations that runs off the main thread.

Let's see a quick example: https://svelte.dev/repl/7bc94b49825f47728444fe8b0ed943cc?version=3.19.2

```html
<script>
    import Visibility from './Visibility.svelte'
    import {fly} from 'svelte/transition';
</script>

<!-- styles here, omitted for brevity -->

<main>
    <h1>Scroll down</h1>

    <Visibility steps={100} let:percent let:unobserve>
        <section>
            <span class="top-left">{percent}%</span>
            <span class="top-right">{percent}%</span>
            <span class="bottom-left">{percent}%</span>
            <span class="bottom-right">{percent}%</span>

            {#if percent > 70}
                <img alt="Robot"
                     in:fly={{duration: 1000, x: -500}}
                     out:fly={{duration: 500, y: -500}}
                     src="https://robohash.org/svelte-is-awesome.png">
            {/if}
        </section>
    </Visibility>
</main>
```

You can see this in action, if open up your Dev tools and inspect the `<img>` element and you should see something like `style="animation: 1000ms linear 0ms 1 normal both running __svelte_701641917_0;"`


## Wrapping up

I will continue to explore Svelte and I hope you will too. There's a lot I haven't talked about, one thing that comes to mind is the reactivity and the `$:` symbol. 

But I highly recommend going through the [Online Tutorial](https://svelte.dev/tutorial) because it will explain it way better than I could and you'll be able to code along in the REPL.

With statements and error handling

Dan Strandberg — Fri, 31 Jan 2020 20:30:46 +0000

With statements are great when we need to handle the possibility of failure in series of steps where each step depends on the result of the previous one.

If you haven't used with statements before you might turn to nested case statements. Let's see an example where we compare them both.

Note: I've made a code choice to pinpoint a problem you might run into when using with statements so we later can learn how to address it.

defmodule Example do
  def run(:case, %{user: user, action: action}) do
    case get_user(user) do
      {:ok, user_actions} ->
        case allowed_to_perform(action, user_actions) do
          {:ok, action} ->
            execute_action(user, action)

          nil ->
            handle_not_allowed(user, action)
        end

      nil ->
        handle_user_not_found(user)
    end
  end

  def run(:with, %{user: user, action: action}) do
    with {:ok, user_actions} <- get_user(user),
         {:ok, action} <- allowed_to_perform(action, user_actions) do
      execute_action(user, action)
    else
      nil ->
        {:error, "#{user} not found or not allowed to perform action #{action}"}
    end
  end

  defp get_user("Bob"), do: {:ok, ["read", "create", "edit"]}
  defp get_user("Anton"), do: {:ok, ["read"]}
  defp get_user("Veronica"), do: {:ok, ["read", "create", "edit", "delete"]}
  defp get_user("Sabrina"), do: {:ok, ["read"]}
  defp get_user(_), do: nil

  defp allowed_to_perform(action, allowed) do
    if action in allowed, do: {:ok, action}, else: nil
  end

  defp execute_action(user, action) do
    {:ok, "#{user} is performing action #{action}"}
  end

  defp handle_user_not_found(user) do
    # Do other user related stuff here
    {:error, "User #{user} not found"}
  end

  defp handle_not_allowed(user, action) do
    # Do other action not allowed stuff here
    {:error, "#{user} is not allowed to #{action}"}
  end
end

Let's take the code for a quick spin to see the differences in action. We add our code to example.exs and load it: iex example.exs

iex(1)> Example.run(:case, %{user: "Anton", action: "read"})
{:ok, "Anton is performing action read"}
iex(2)> Example.run(:with, %{user: "Anton", action: "read"})
{:ok, "Anton is performing action read"}

iex(3)> Example.run(:case, %{user: "Anton", action: "create"})
{:error, "Anton is not allowed to create"}
iex(4)> Example.run(:with, %{user: "Anton", action: "create"})
{:error, "Anton is not found or not allowed to perform action create"}

iex(5)> Example.run(:case, %{user: "Jason", action: "read"})
{:error, "User Jason not found"}
iex(6)> Example.run(:with, %{user: "Jason", action: "read"})
{:error, "Jason is not found or not allowed to perform action read"}

As you can see they don't behave the same, the error messages are more specific when using the case statement.

The case statement have an edge here because both get_access/1 and allowed_to_perform/1 returns nil when they fail (on purpose 😈). We can easily handle them separately by calling handle_user_not_found/1 and handle_not_allowed/1 respectively in each case.

For the with statement we match on what we have available in the else block and that's nil, so we don't know which one has failed. One might suggest we should return {:error, reason} and match on that.

It would work, we can match on the reason as long as they are different. In our example the functions are private and local, but this is not always the case, we could have called an external library and be in the same position as now.

We could stick with case statements but I would argue that nested case statements are hard to follow, we only have two levels here but imagine we had three or more.

What we want is to be able to use the with statements but still be able to differentiate between the errors. So are we out of luck? Not yet, there's a "trick" we can use.

Tag, you're it!

By wrapping the code in a tuple we can tag the expressions so we can match on the tags in case of failure.

  def run(:with, %{user: user, action: action}) do
    with {_, {:ok, user_actions}} <- {:get_user, get_user(user)},
         {_, {:ok, action}} <- {:check_allowed, allowed_to_perform(action, user_actions)} do
      execute_action(user, action)
    else
      {:get_user, _} -> handle_user_not_found(user)
      {:check_allowed, _} -> handle_not_allowed(user, action)
    end
  end

On the right side we use {:some_tag, fn(args)} and match on it on the left side. Here we don't care about the tag so we can ignore it and match on the result of the function calls.

If any of the matches fails we enter the else block and now we can tell them apart by matching against our tags :get_user and :check_allowed.

Let's apply the changes and try it: iex example.exs

iex(1)> Example.run(:with, %{user: "Anton", action: "create"})
{:error, "Anton is not allowed to create"}

iex(2) Example.run(:with, %{user: "Jason", action: "read"})
{:error, "User Jason not found"}

Now we the get same specific errors as the case statement and we didn't need to modify the return values. 😀🎉

How to fix your history

Dan Strandberg — Sun, 26 Jan 2020 13:49:26 +0000

When developing it's encouraged to commit often and use good commit messages, but sometimes it can git messy.

Imagine we got this feature branch with some undesired commits. We retrace the steps taken to see what happened. This example is a bit contrived but please bare with me.

There's a bit of typing to be done. You can copy from this gist into your terminal to avoid having to type it all in.

$ git init
$ echo "A bunch of project files ..." > project.txt
$ git add project.txt
$ git commit -m "Initial commit"

Moving on the the feature branch ...

$ git checkout -b new-killer-feature
Switched to a new branch 'new-killer-feature'

$ echo "A lot of coding being done... looking god." > component.txt
$ git add component.txt
$ git commit -m "Add first component"

Fixing the typo (good not god) but we're in a flow so we add it the wrong commit by mistake.

$ echo "A lot of coding being done... looking good." > component.txt
$ echo "More code here ..." > anotherComponent.txt
$ git add .
$ git commit -m "Add another component" -m "With a really long descriptive message..." -m "With details and important information..."

$ echo "Creates code for business logic ... and fn -> 100/Oops" > businessLogic.txt
$ git add businessLogic.txt
$ git commit -m "Add business logic"   

$ echo "Add a third component ..." > thirdComponent.txt
$ git add thirdComponent.txt
$ git commit -m "Add third component"

We stop and try the code and it's not working, we need to fix the oops.

$ echo "Add for business logic ... fn -> 100/5" > businessLogic.txt
$ git add businessLogic.txt
$ git commit -m "Fix error in business logic"

It should be a 4 not 5, obviously.

$ echo "Add business logic ... fn -> 100/4" > businessLogic.txt
$ git add businessLogic.txt
$ git commit -m "Fix business rule"

So what happened

First a typo found its way into our component, when it later got fixed it was staged and added to the wrong commit. Then some erroneous business logic got committed, a third component were added before the error was detected. The error got fixed as well as some business rules.

This is how our branch looks now:

git --no-pager log --oneline

4dc57a6 (HEAD -> new-killer-feature) Fix business rule
0ea4f69 Fix error in business logic
2449165 Add third component
6f750fc Add business logic
f09f39e Add another component
a59d39a Add first component
34f47d9 (master) Initial commit

Maybe it's not that bad? Could we get away with it? Probably! But remember this is over simplified, a real world example might be messier.

So let's continue and see what we can do about it.

Interactive rebase to the rescue

With interactive rebase we can rewrite the history. So we issue the command git rebase -i <branch>. We use the master branch, it hasn't been modified so there should be no conflicts going forward.

$ git rebase -i master

This should open a dialog like the one below.

pick a59d39a Add first component
pick f09f39e Add another component
pick 6f750fc Add business logic
pick 2449165 Add third component
pick 0ea4f69 Fix error in business logic
pick 4dc57a6 Fix business rule

# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
#   However, if you remove everything, the rebase will be aborted.
#
#
# Note that empty commits are commented out

Notice the comments (#) above, it describes the available commands and we are going to use some of them.

Now if you remember the typo fix, it was added to Add another component, but the typo was done in Add first component so the fix should really be part of that commit.

So the first thing we need to do is to modify the Add another component, so we change it from pick to edit. (#1)

Then we have the two fixes for the business logic, it would be great if they could be apart of the original commit. So we move them up right below the Add business logic and change from pick to fixup. (#2)

pick a59d39a Add first component
edit f09f39e Add another component (#1)
pick 6f750fc Add business logic
fixup 0ea4f69 Fix error in business logic (#2)
fixup 4dc57a6 Fix business rule (#2)
pick 2449165 Add third component

When we save and exit the commands above will be executed from top to bottom, at the edit command it will stop so we can make changes.

$ git --no-pager log --oneline

f09f39e (HEAD) Add another component
a59d39a Add first component
34f47d9 (master) Initial commit

The HEAD is pointing to Add another component, now let's do a reset on that commit.

$ git reset HEAD~
$ git --no-pager log --oneline

a59d39a (HEAD) Add first component
34f47d9 (master) Initial commit

Run git status and it should show component.txt (modified) and anotherComponent.txt (untracked), also notice how the HEAD now points to Add first component.

The component.txt (modified) holds the typo fix and HEAD is pointing to the commit where the typo happened in the first place. So to undo it we can simply stage and amend like so:

$ git add component.txt
$ git commit --amend

We still need the handle the anotherComponent.txt though and the git reset HEAD~ command undid the commit associated with this file.

This is not ideal because that commit message held a lot of important information that we don't want (or remember) to retype. So how do we fix this?

There's a neat feature we can use, it's called ORIG_HEAD. It's the previous state of HEAD after a possible dangerous operation which git reset HEAD~ qualifies as. So what we do:

$ git add anotherComponent.txt
$ git commit -c ORIG_HEAD

The -c flag above is saying re-edit message, so we get the previous message we had in HEAD and use it as the commit message.

That's it! We undid the typo altogether when we amending the fix to Add first component and Add another component has only relevant files/changes.

Now we can continue the rebase process ...

$ git rebase --continue
Successfully rebased and updated refs/heads/new-killer-feature.

$ git --no-pager log --oneline

aee1f72 (HEAD -> new-killer-feature) Add third component
cebe196 Add business logic
5a2573d Add another component
ab87670 Add first component
34f47d9 (master) Initial commit

The two fixup command got executed, those changes got applied to Add business logic as if those errors never happened.

Is it dangerous?

Git rebase is powerful tool, it's also easy screw things up if you don't know what you're doing, so let's screw it up a bit together. We are in the new-killer-feature branch just as we left it.

$ git rebase -i master

pick c14c5e0 Add first component
pick 8b6f9f2 Add another component
pick fe055bf Add business logic
pick 85963e5 Add third component

Now we remove all but the first commit.

pick c14c5e0 Add first component

Now we're in pickle right? Well not really, because we can use git reflog and go back to just before we did our mistake (after we finished our last rebase).

$ git --no-pager reflog

9e51b2e (HEAD -> new-killer-feature) HEAD@{0}: rebase -i (finish): returning to refs/heads/new-killer-feature
9e51b2e (HEAD -> new-killer-feature) HEAD@{1}: rebase -i (pick): Add third component
b8a72f8 (master) HEAD@{2}: rebase -i (start): checkout master
85963e5 HEAD@{3}: rebase -i (finish): returning to refs/heads/new-killer-feature

... 

$ git reset --hard 85963e5

Note: You'll get your own hashes (change 85963e5 to your own)

And we're back in business. Now I encourage you to learn more about rebase because there's a lot of stuff I've not covered in this post.