DEV Community: Thomas Pikauli

Relations, including nested data and more Prisma 2 notes

Thomas Pikauli — Sat, 26 Sep 2020 11:06:23 +0000

I'm currently exploring a new back-end technology called Prisma 2.
I want to share some notes here, as I discover how it works, in the hope that they might be useful to anyone trying out Prisma 2 too (^-^). If you're not into coding, javascript, graphql or all that stuff, it probably won't be too interesting for you. Of course, you're welcome to read the notes anyway.

A little background: Prisma 2 is the successor to Prisma, which is a database layer that provides you with easy access to a database. It's done in graphql style, so you can make those nice 'buffet'-like queries where you pick and choose the data you need.

The new Prisma mostly does the same thing as the previous Prisma, but it works completely different under the hood, which allows for us as developers to be a bit more explicit about how we use the technology. That usually also means we need to dive a little deeper into the stuff that was previously sheltered from us.
Hence, here I am, discovering the 'quirks', or rather just how things work.

Schema

The Prisma 2 schema is where you model your database. You tell Prisma what you need and how things are related, and in turn it will set up the database for you.

Making the schema is for the most part quite intuitive. I highly recommend installing the VSCode plugin if you're using VSCode. It immediately shows you when you make typos, or do any illegal stuff. Naturally with illegal stuff I mean instance where you are trying to create relations that are impossible or using scalar values that don't exist.

Especially the relations need extra attention if you're coming from the previous Prisma or even Graphcool. It isn't quite as straightforward anymore as it was... but that's for the best. That's my feeling at least.

Prisma 2 relations

Many-to-many relations can be done implicitly or explicitly with a connection table between the two types. If you want to have fields on the connection, then a connection table is preferred. For most cases an implicit many-to-many will work.
One-to-one or one-to-many relations always needs a foreign key. If it's one-to-many or many-to-one, it needs to be on the 'one'. If it's one-to-one you can choose on which model you place it.
If there are multiple relations to the same model on a model, you need to give the relation a name.

Setting up Prisma 2 with Apollo Server

After you've written out your database schema, have Prisma migrate your database, and then generate a corresponding schema for your back-end, you can worry about your server.

I am using a NodeJS server, and since I want to expose a graphql API to my frontend, I would like to use Apollo Server. It's a solid and well-known technology that provides a lot of functionality.

How to setup Apollo Server in conjunction with Prisma 2 isn't really properly documented anywhere at the time of writing. But you can definitely use Prisma 2 with Apollo Server without having to use stuff like Nexus. It's actually quite easy.

The way I set it up is to simply configure the Apollo Server as you normally would, but then pass in Prisma 2 in the context.

const server = new ApolloServer({
    typeDefs,
    resolvers,
    context: createContext,
});

And your context function could look a little something like this:

const prisma = new PrismaClient();

function createContext({ req }) {
    const token = req.headers.authorization;
    // possibly do some authentication stuff
    // or maybe something else :)
    return { prisma, token };
}

That's pretty much it.

Querying and Mutating

Finally you should be able to query and mutate from your Apollo Server. On gotcha I should give you a heads up about:

When you query nested types you need to either 'include' or 'select' them. The same goes for retrieving data after a mutation. This got me at first, where I wondered the better part of a day where my data went. The docs had the answer, but coming from the previous Prisma I just didn't expect this behaviour.

I'll update this entry as I gather more notes. More of my writing is over at my personal blog: Just Some Notes

Making a custom color picker

Thomas Pikauli — Sun, 31 May 2020 10:34:02 +0000

Colors are fun. Especially when you can choose your own. You’ll need a color picker for that though. Luckily, we can easily create a custom one ourselves with react.

While you can use the native color picker that the browser offers, we’ll be using the library react-color. It provides us with a couple of helpful components, which speed up the progress of making a picker. So first we install react-color.

yarn add react-color

Once installed we can immediately started coding. The library is built in such a way that it offers a higher order component that you need to wrap around a component of your own. The higher order component provides you with functionality we’ll go through later. First let’s import the HoC and make a component to wrap around.

import {CustomPicker} from "react-color"

class ColorPicker extends React.Component {
    render() {
        return (
            <div>
            our amazing picker
            </div>
        )
    }
}

and then let’s wrap the CustomPicker higher order component around it.

const ColorPickerWrapped = CustomPicker(ColorPicker);

If at this point you console.log the this.props of the ColorPicker component, you see that we’ve just got a bunch of props.

color: Object
hsl: Object
hex: "#22194d"
rgb: Object
hsv: Object
oldHue: 250
source: undefined
onChange: function () {}

There is a color prop we’ll discuss in a minute, but there are also an hsl prop, a hex prop, a rgb prop and an hsv prop. These are all color formats that may or may not be useful too you. The great thing about the library is that it provides you with all of them, and is fine with you providing only one.

Let’s get to that color prop. We need a piece of state to keep track of the color we’re selecting in our yet to make picker. We’re going to keep that state not in the ColorPicker component itself, but we’re going to lift it a component higher.

export default function App() {
    const [color, setColor] = useState("#FFF000");
        return (
            <div
            style={{
                position: "fixed",
                width: "100%",
                height: "100%",
                margin: 0,
                padding: 0,
                background: backgroundColor
            }}
            >
                <h1>A Custom Color Picker with react-color</h1>
                <ColorPickerWrapped
                    color={color}
                    setColor={setColor}
                />
            </div>
        );
}

As you can see we created a new component that keeps the color in a piece of state. We pass that state as a prop to our earlier wrapped ColorPicker. The reason that we keep this state in a parent component, is that the prop needs to passed to the wrapping component to do its converting magic. If you check the props again of the ColorPicker you can now see that the default hex color we provided in the state has now been converted to rgba, hsl and hsv for us. We still can’t change the color though. Let’s include one of the helper components from react-color. We can start with a simple one: a simple input to change the hex code of the color.

var { EditableInput } = require("react-color/lib/components/common");

<EditableInput
  value={this.props.hex}
  onChange={data => this.handleChange(data.Hex)}
/>

The EditableInput component needs at the minimum these two props: a value prop to display what the value of the input field is, and an onChange handler to handle the new values that are typed into the field. We can use the hex prop from the higher order component for the value. For the onChange handler we need to create a little function.

handleChange = data => {
    this.props.setColor(data);
};

It just takes the Hex property of the data object and then calls the setColor function we passed down from the parent component. That will change the color in the state, which is then passed down again and correctly displayed in the input field. We now have a very bare bones custom color picker!

Still, this is no fun. We need a saturation picker. Let’s import it and set it up.

<div
    style={{
        float: "left",
        width: "200px",
        height: "200px",
        position: "relative"
      }}
>
    <Saturation
        {...this.props}
        onChange={this.handleChange}
        pointer={Picker}
    />
</div>

Okay, this one has some more meat on the bones. First off, you need to wrap this component in a div with position: relative. This is because the Saturation component is positioned absolute. Next the component needs the props the wrapper provides. So might as well pass ‘em all down by destructuring this.props.

The onChange should seem familiar. You can use the same helper function, but no need to specifically pass a property of an object. Just pass it all! Then there is the pointer prop. It is optional and you can leave it empty. However, you may also pass a custom component to configure your own little picker. Let’s do that quickly.

function Picker() {
return (
        <div
        style={{
            width: 20,
            height: 20,
            borderRadius: 20,
            background: "rgba(255,255,255,0.2)",
            border: "1px solid white",
            boxShadow: "0px 2px 4px rgba(0, 0, 0, 0.25)",
            boxSizing: "border-box"
        }}
        />
    );
}

Ok done. Save the file and now behold a very cool saturation picker. The fun thing is that you should see your hex input field be updated as you drag the picker across the saturation picker. And vice-versa.

In the same vain we can now also add a hue picker.

<div
    style={{
        float: "left",
        width: "200px",
        height: "20px",
        position: "relative"
      }}
>
    <Hue
        {...this.props}
        onChange={this.handleChange}
        pointer={Picker}
      />
</div>

You’ll notice there isn’t much different from the saturation picker. While we’re at it let’s also include an alpha picker. This will let us select a see-through shade :)

<div
    style={{
        float: "left",
        width: "200px",
        height: "20px",
        position: "relative"
      }}
>
    <Alpha
        {...this.props}
        pointer={Picker}
        onChange={this.handleChange}
      />
</div>

Awesome! We’ve now created a pretty cool color picker. Let’s put it into practice. How about we use the color picker we just created to change our background color. First we’ll need to set up some state in the parent component, and some styling.

export default function App() {
const [color, setColor] = useState("#FFF000");
const [backgroundColor, setBackgroundColor] = useState("#FFFFFF");
return (
    <div
    style={{
        position: "fixed",
        width: "100%",
        height: "100%",
        margin: 0,
        padding: 0,
        background: backgroundColor
    }}
    >
    <h1>A Custom Color Picker with react-color</h1>
    <ColorPickerWrapped
        color={color}
        setColor={setColor}
        setBackgroundColor={setBackgroundColor}
    />
    </div>
    );
}

So there is now some state, a function to set the background color and we’ve added styling based on the state.

Since we’ve got those fancy pickers we don’t want to suffice for just a regular ol’ hex color, we want a rgba color with alpha. We know that react-color provides the values we need for that. So basically the only thing we need to do is create a button that confirms our color choice, and then have a helper function that takes the rgba value from the higher order component, which is then passed into the setBackgroundColor function as valid css.

selectColor = color => {
    const rgba = `rgba(${color.r}, ${color.g}, ${color.b}, ${color.a})`;
    this.props.setBackgroundColor(rgba);
};

<button onClick={() => this.selectColor(this.props.rgb)}>
    Select a color
</button>

There we go. The rgb prop from the HoC provides us with an object that contains the seperate values for the r, g, b and a. Our styling expects an rgba value that is formatted like: “rgba(r,g,b,a)”, so all we need to do is format it like that using a template string.

With those additions in place we have completed our custom color picker. You may now include your own styling, fantasy and use it in the wild.

Full code: https://codesandbox.io/s/just-a-custom-color-picker-uu6v3?file=/src/App.js
Original post: https://justsomenotes.com/making-a-custom-color-picker/

How to build your own analytics (part one)

Thomas Pikauli — Sun, 10 May 2020 14:18:36 +0000

I have a blog (just some notes). It’s just a personal site I occasionally share some stuff on. That’s all it is, and all it ever should be. Naturally, like most humans on the internet, I do get a little positive sensation when people visit my site. But that’s really just a bonus. It’s not a reason to post more stuff or to post things I normally wouldn’t care so much about.

That is my official stance.

Knowing myself, I sometimes tend to deviate from my official stance; especially when I share content that people actually consume and really seem to appreciate. So I need to protect myself against these urges to play to an (imagined) audience.

I found analytics plays a key part in this process (negatively!). It’s a nice little feeling to know someone from another part of the world has visited your website. It’s a great feeling to know that a hundred people read your stuff while you were sleeping. But I definitely get the “I NEED TO MAKE MORE OF THIS”-jitters whenever I find out article X was read a lot by people who came from site X and used search term U and now probably want more.

In other words, when you get all Google Analytics about your website, it changes your mindset, and potentially your approach to what you were doing. And that’s not necessarily bad. However, when you just want to keep your thing your thing, I do experience it as detrimental.

So, what’s next. No more analytics? It’s a valid option, but also boring.

It led me to think about my early days on the web. When I still had websites with a little visible counter. Or in a more advanced stage a little Nedstat button that people could click on to publicly view my stats.

Well, you can guess what happened next. Nostalgia took over. I decided to make my own analytics. How hard could it be right? Just add another entry in the database whenever someone hits your site. And as an added bonus I also donate a little less data into the arms of the tech giants (or less directly).

So let’s make a little recipe for this analytics app. What do we need to get this thing running. I made a pact with myself though. This couldn’t suck up all of my time or stress me out. So if a thing seems too difficult or convoluted, I just leave it out. The bare minimum is just to count visitors, anything extra is a bonus.

The recipe

a server to handle business logic
I'm familiar enough with Javascript, so a NodeJS server seems appropriate.
a database to save data
Not really a DB-guy, but PostgreSQL I recently installed on my PC for other reasons. Might as well use it.
a way to log data on my blog and send it to the server
My blog uses Gatsby, so that will probably mean a thing or two.

Let’s log some stuff

If we can’t log a visitor, we don’t even have to start setting up the other stuff. So let’s start with looking what we can log using the browser. Now as I said, my blog is made with Gatsby, it’s a static site generator that uses React. If you don’t use Gatsby, that isn’t much of a problem. I’ll point out where things deviate.

The important thing is to log someone as soon as they enter your site. After that we need to log when they click on a link to another page. So if you’re site consists of five separate pages, each page would need a script that runs when the page has loaded.

Modern websites and apps however do not necessarily have different pages in the traditional sense. They often ‘fake’ other pages by changing the url, and then have the script on the single page show different content programmatically.

Gatsby uses a system like that. So we need to have a way to access that system so we can plant our little loggers. Thankfully Gatsby provides a file called gatsby-browser.js. This file contains two functions that are of use to us:

onClientEntry
onPreRouteUpdate

The first function runs only when you initially open the website, while the latter runs on each subsequent navigation to another page on the website. Both are thus very usable for us. Let’s start with onClientEntry. What kind of information would we be able to gather at this point?

The browser provides us with a Window object, which in turns gives us access to other objects which all have tiny pieces of information that might interest us.

const language = navigator.language
const browser = getBrowser()
const page = window.location.pathname
const referrer = document.referrer
const dimensions = window.screen.width + " x " + window.screen.height

Let’s look at the code. There is navigator object that provides us with the browser language, there is a location object that gives us a pathname, there is also a document object which can give us a referring website. Lastly there is a screen object that provides us the width and height of the browser.

And then there is the browser itself, which we might want some information about. This is however always a bit murky, since things change often in browserland which makes any code that tries to identify browsers unreliable. Yet, you can always make an attempt, and I would suggest to do a google search for the latest logic and/or library which can help you with this.

With all this information we now have a faint clue about our visitor. We know their language, whether they were referred from another website and we can estimate whether they were on mobile, tablet or desktop by combining the browser and dimensions information.

So just to be clear, all this information can also be gathered on non-Gatsby websites. Each website provides those objects. So for a regular multi-page website, you can make one small script that you run on each separate page. Back to Gatsby.

For the onPreRouteUpdate things are not that different. Only this function provides us with a prevLocation object. So this is useful to check if it provide us with a referrer. Or in other words: on which link did my visitor click to end up on this page.

const referrer = document.referrer
    ? document.referrer
    : prevLocation
    ? prevLocation.href
    : "Unknown"

So now we gathered most of the information we want to have, we have to send it to a server to process it and save it to a database. We can create an addVisit function for that.

async function addVisit({ page, browser, language, referrer, dimensions }) {
    try {
        const response = await fetch(url, {
        headers: {
            Accept: "application/json",
            "Content-Type": "application/json",
        },
        method: "post",
        body: JSON.stringify({ page, browser, language, referrer, dimensions }),
        })
    } catch (error) {
    console.log(error)
    }
}

As you can see it’s a quite straightforward fetch that sends a JSON package to a server we have yet to build, which is referred to by the url variable. To finish up our frontend work it’s a good idea to already use an environment variable to prevent us from logging our local visits to the future server.

const url =
    process.env.NODE_ENV === "development"
    ? "http://localhost:8002/stats"
    : "https://serverweneedtobuild.com/stats"

Now is there anything we missed or any information we still might want to know? Well, obviously we want to have the date and time of the visit, and other than that I always like to know which country the visit is from. Both of these however we’re going to take care of on the server. So that’s exactly what the next article is going to be about: the server.

We’ll be setting up a nodejs server that takes our information package, processes it, adds some extra info and then saves it to a database. And then when that is done, we’re going to make a nice little public stats dashboard so you can see how many people visited my blog (yikes!). But that’s for part three.

Originally posted on just some notes

It takes a village (and a few elders)

Thomas Pikauli — Fri, 13 Mar 2020 09:52:34 +0000

For too long I have ventured into the unknown, not caring about all the beautiful things I built in the past and then left behind. Those buildings would still be there when I came back, I believed. Maybe they’d need a little checkup, but as long as one of the inhabitants wasn’t screaming that the roof was gone, I was still good. And I… I could continue my adventures into the unknown, building new cities and villages on top of my beautiful intricate infrastructure.

Recently though, complaints about broken things have started to stack up. Every time I go out to build new stuff, one of the villagers calls me back. Telling me I should fix a door, a window or a leaking sink. It leaves us both frustrated, because this must be the sixth time I fixed something in his house.

I have now quit venturing into the new altogether, instead sticking to the structures I have already built. Making them more sturdy, more pretty and using simpler techniques.

The villagers are content with my new dedication to their homes, but always when I walk through the streets I see the elders softly shaking their heads and smiling their sad old smiles. I ignore them. They always have comments about my work… but didn’t I build this very city with my own two hands?

It wasn’t until much later, when I almost burnt myself out chasing ever more complex complaints, that somehow deep inside me something changed. I realized I couldn’t go on this way. There had to be a way to construct my buildings without me constantly having to fear I break an electricity cable somewhere in another part of town. There had to be a measure I could take. A new paradigm to follow.

It was time to seek out the knowledge I had discarded and ignored for so long. It was time to make a change. And when you look for what you need with a genuine want, it will seek you out.

Recalling the comments of my elders, it came to me that I needed to build my structures in ways easy to reason about for everyone. And that meant I couldn’t just throw bricks at it from day one. When I start out with designing the construction of the buildings first, I can write instructions about how to do simple regular checkups on their inner workings. And then I can have the inhabitants themselves regularly check the status of their homes, and directly report to me when a checkup fails. This way a window won’t actually break when I start to mess with the underlying infrastructure or build a brand new home. Because believe me: I have built small little sheds, only to hear of complaints from house owners on the other side of town being without heating.

While with this new way of working the stream of difficult problems hasn’t immediately stopped flowing, I did notice with each passing week that the stream lost some of its strength. Now the problems are of superficial nature, issues I can tend to directly, or sometimes even prevent. Nothing festers under the floorboards anymore. No more twenty roofs flying off into the nightsky.

Now when I walk the streets of my little villages and towns I see the people taking pride in their homes. And the elders… I think I saw one of them give me an approving nod the other day.

Originally posted on: https://justsomenotes.com

I used effects, said goodbye to my lifecycles, and feel 🙂

Thomas Pikauli — Mon, 11 Feb 2019 18:44:23 +0000

Last week Hooks were finally added to React. It is now possible to use state in a function. At least, that much I remembered from watching the initial announcement way back when. But lifecycles though... I had no idea how they were supposed to work. I decided to read the docs and experiment.

Let's experiment

Let's try and build a little app that keeps a few bits of state and does things based on state changes. Normally I would look to my beloved componentDidUpdate for this, but she's gone... well not really: classes will very much remain part of React, but still... I might have already said goodbye to them.

Okay, the 'app'. Let's create a numerical input field with an onChange handler, a button to add said input to whatever the input was before, and finally a button to switch from dark to light mode and vice-versa (somehow everyone seems to love that).

The initial state for that in our Hookian Age would look a little something like this:

function App() {
  const [lights, setLights] = useState(true);
  const [input, setInput] = useState(0);
  const [sum, setSum] = useState(0);
}

Next up we're going to hook it up to HTML elements, just like we'd do in our classes.

return (
    <div
      style={{
        padding: 15,
        fontFamily: "Arial",
        background: lights ? "salmon" : "black",
        color: lights ? "black" : "white"
      }}
    >
      <h1
        style={{ fontFamily: "Times New Roman", margin: 0, paddingBottom: 15 }}
      >
        Sumple UseEffect
      </h1>
      <div>
        <strong>Sum:</strong> {sum}
      </div>
      <div style={{ marginTop: 15 }}>
        <input
          type="number"
          value={input}
          onChange={e => setInput(e.target.value)}
          style={{ width: 50 }}
        />
        <button onClick={handleSum}>
          +
        </button>
      </div>
      <div style={{ position: "absolute", top: 30, right: 30 }}>
        <button onClick={() => setLights(!lights)}>
          Lights {lights ? "off" : "on"}
        </button>
      </div>
    </div>
  );

Hopefully this doesn't look weird to you. The only thing that's missing from the code is the handleSum function. It looks like this:

  function handleSum() {
    setSum(Number(sum) + Number(input));
    setInput(0);
  }

It's defined within our App function and simply adds the input state to our sum state; and then sets the input back to zero. We should have a working app now. So far, so good.

We Use Effects

Now we've decided we want to validate the numerical input. If the value is 0 or above a very arbitrarily chosen number of 480, we're going to disable the + button. Granted, we don't actually need an extra piece of state for this, but let's just do it anyway.

We create valid as a piece of state.

  const [valid, setValid] = useState(true);

and then we add disabled to our button.

  <button disabled={!valid} onClick={handleSum}>
     +
  </button>

If we were still using classes we could have done something like this.

componentDidUpdate(prevProps, prevState) {
  if(prevState.input !== this.state.input) {
     if (this.state.input > 480 || this.state.input === 0) {
        this.setState({valid: false});
      } else {
        this.setState({valid: true});
      }
  }
}

But we're not. So we don't have componentDidUpdate. Instead we do have useEffect, a function that React promises to run after each render. That's convenient, because each change in input triggers a render. So we can use useEffect to do our validation.

  useEffect(
    () => {
      if (input > 480 || input === 0) {
        setValid(false);
      } else {
        setValid(true);
      }
    },
    [input]
  );

Our new friend accepts a function as a first argument, and an array as an optional second argument. I hope that the function makes sense, but I would understand if you have questions about the lack of comparing state and the array. Luckily, those two are connected.

It turns out, you don't have to compare props or state anymore. React allows you to provide the values in the second argument you want to run useEffect on. So in our case useEffect will only run on changes in input.

Did we mount?

So we now have a way to 'do stuff' based on changes in props or state. But how about that initial lifecycle that used to help us set up subscriptions? Or that one that allowed us to clean them up again? I'm talking about componentDidMount and componentWillUnMount of course.

We need a way to run useEffect regardless of changes, but not on every change. Preferably only once in the beginning, and once at the end. Luckily, that's very much possible.

  function handleEscape(e) {
    if (e.keyCode === 27) {
      setSum(0);
      setInput(0);
    }
  }

  useEffect(() => {
    document.addEventListener("keydown", handleEscape);
    return () => document.removeEventListener("keydown", handleEscape);
  }, []);

If we leave the array empty in our second argument, React runs our code only once, and treats our return as a cleanup function for when our component unmounts. In our case we can use it to add a listener to reset our sum and input when someone presses escape.

But what about our other useEffect? Do we have to merge them...?

The answer is NO! You can use multiple useEffects within the same component. Which is great, because we're going to add even more. I'm very curious to see how many times I change the lights or sum.

So we set up another useEffect and fill our array with lights and sum. Now this effect will only run when either lights or sum changes. It's good, but I just realized I want to know which of the two changed so I can keep more detailed stats.

The answer is actually to make two useEffects, but I dream back to the days (yesterday) when I still used classes and want to do a comparison between previous and current values, so I find out myself which one changed. How to get those previous values though? The React docs provide us with a helping hook.

function usePrevious(value) {
  const ref = useRef();
  useEffect(() => {
    ref.current = value;
  });
  return ref.current;
}

It's used like this:

  const previousValues = usePrevious({ lights, sum });

So what's happening is that we pass our state values into the function, they are then saved in a ref and that ref is returned. This ensures we do not get the latest values, but the previous values. That might seem much more difficult then it needs to be, but remember that we could have just used two useEffect functions each with the other value in the second argument.

Let's complete our single useEffect though:

  useEffect(
    () => {
      if (previousValues && previousValues.lights !== lights) {
        const newActions = Object.assign({}, actions, {
          lights: actions.lights + 1,
          total: actions.total + 1
        });
        setAction(newActions);
      } else if (previousValues && previousValues.sum !== sum) {
        const newActions = Object.assign({}, actions, {
          sum: actions.sum + 1,
          total: actions.total + 1
        });
        setAction(newActions);
      }
    },
    [lights, sum]
  );

That works. We now have a log of which actions have been used. Let's render it on the page.

  <div>
    <strong>Actions:</strong> {actions.total}
  </div>

Have we exhausted our useEffect trickery? We have not. How about one that runs on each render? That would allow us to count how many renders we see right? Could be interesting. Let's do it.

But wait. Even if we have a useEffect that runs after each render, how will we save our amount of renders without triggering another render? We can useRef for that.

  const renders = useRef(0);

We initialize the ref with 0. Then we create another effect.

  useEffect(() => {
    renders.current = renders.current + 1;
  });

Since the current property of a ref is mutable, we can assign our new value to it. But did you notice how our useEffect doesn't have a second argument? I think I mentioned it before, but the second argument is optional. If you do not provide it, the useEffect runs on each render. Perfect for this case.

All that's left is to render our render count on the screen.

  <div>
    <strong>Renders:</strong> {renders.current}
  </div>

Yes, you can just render the current value of the ref. Awesome!

Am I happy?

After writing this app I wonder if I'm happy with all of this. To be honest, I think I am. While useEffect takes a bit of getting used to, it's very versatile. That might also be its 'problem'. Although, once you really start using useEffect you may not find that a problem at all.

It probably will take a bit more time before I get really comfortable with Hooks and all that they bring with them, but I already feel their potential. If you have the space and time to experiment with them, I strongly recommend to do so. There's no hurry, but they're cool. They really are 🙂.

Full code if you are interested.

Can you hand write a website in Notepad?

Thomas Pikauli — Sun, 03 Feb 2019 14:05:19 +0000

I'm deep into VS Code. My React application grows like cabbage. With Prettier, ESLint, IntelliSense and Hot Reloading by my side, I can't really be stopped. I fix bugs, avoid files that have too much awful and complex code for me to stomach, and admire a couple of beautifully simple components that render incredible results on the screen using sophisticated chained array methods and smart dynamic styling.

Suddenly my mind wanders off to the millennium. I remember back then I made websites too. For the longest time I was creating my sites in Microsoft Frontpage. Table after table, image after image, font after font; I was building little shrines dedicated to all my hobbies. I also learned a little HTML from a book my mother bought me.

So after a while, each time Frontpage refused to do what I wanted it to do, I opened up my index.html in Notepad. I searched for where I placed text I knew I could read to locate where the code should be adjusted. With a bit of trial and error I got better and better at it.

At one point I didn't really need Frontpage anymore to create a layout. I was just writing pure HTML. I don't think I even knew what CSS was. I designed my layouts in Photoshop, sliced 'm up in little pieces and then fit them into tables. It seemed I had a lot of fun back then, but it got me to wonder though...

Can I still hand write a website in Notepad like I did back then, without looking up anything on Google?

Well... I tried... and the answer is yes. But it's not pretty, it hurt my head and I don't think I ever want to do it again.

Anyway, here's my shameful attempt at hand writing a simple three column website as if I was 12 years old again. I discovered that modern browsers are very forgiving of my mistakes and that I'm blessed to know how CSS works at my now very advanced age.

<html>
  <head>
    <title>My Handwritten Webpage</title>
  </head>
  <body>
    <table width="1000px">
        <td bgcolor="blue" width="200px">
          <font color="white" face="tahoma"><b>Navigation</b></font>
          <ul>
            <li><a href="index.html"><font color="white">Home</font></a></li>
            <li><a href=""><font color="white">About</font></a></li>
          </ul>
          <br>
          <br>
          <br>
        </td>
        <td width="600px" bgcolor="red">
           <table>
             <tr>
               <td>
                 <marquee>
                   <font color="white" face="verdana" size="4px">My Handwritten Webpage</font>
                 </marquee>
               </td>
             </tr>
             <tr>
               <td>
                 <font face="arial" size="15px" color="pink"><i>Welcome to my page! I hope you like it :)</i>
                 </font>
                 <br>
                 <br>
               </td>
             </tr>
         <tr>
        <td bgcolor="white">
          <font>This is so very hard... I can't for the life of me remember how to do this... And I forget to refresh to see my updates.</font>
                </td>
         </tr>
           </table>
        </td>
    <td width="200px" bgcolor="orange">
          <font face="tahoma"><b>Affliates</b></font>
          <br>
          <a href="https://dev.to">Dev.to</a>
          <br>
          <br>
          <br>
          <br>
          <br>
          <br>
          <br>
        </td>
    </table>
  </body>
</html>

Here's the result in a CodeSandBox

So, how about you? Can you handle this challenge? Can you write an index.html in pure HTML without any Googling? Show me!

Make art, not apps <3

Thomas Pikauli — Wed, 30 Jan 2019 14:26:53 +0000

One of the most crippling things you can do as a programmer is to try and build an app. Especially an ambitious one. Apps are like buildings. They look cool from the outside and sometimes even quite straightforward to construct, but they require planning, plumbing, foundations, electricity and about 10,000 more things you probably never even thought of.

Not too say you should never build an app. Maybe you have the necessary experience, the right team or the determination and grit of a young pitbull. Or maybe you just want to taste failure so you can learn from it. That's all fine. But disappointment can also really hit your morale in the most unfortunate of places.

So should we build nothing? Of course not. But why not try to go for something more elusive. Something that doesn't require a huge checklist. Something that isn't held hostage by high expectations of how things should work. I promise you, you will still learn how to code. You will still face challenges. And you will still have something to share with the world.

Free your mind

Free yourself from the app meta. Because even if you keep it simple. Even if you limit 'the features', and even if you have the 20/20 vision. When you start with an app; marketing, money & expectations always come creeping up on you like the hungry little predators they are.

You start thinking about the end user, the market, business models, and how you're going to connect Stripe. You worry about performance and scaling. You dream about how your app is going to become that one side project that happened to earn you a lot of money. You end up scheming, while you should be coding.

And the rest will follow

Instead... let's make art. Let's make little games. Let's make interactive stories. Let's make weird stuff. Let's make graphics. Let's make things that surprise yourself and everyone who'll use or see it.

It's okay to build things that seem completely unnecessary. Projects that do little else than make you smile. It's completely fine if you're navigation doesn't make sense. Or if you're project breaks all the patterns that rule our web. Because that work may end up to be the work that inspires me, you and everyone else on this website the most.

So when you just want to code. When you just want to experiment. When you just want to build. Don't always go for an app. Go for something weird. Delight us. And delight yourself!

If you made something cool, I'd love to see it: @ma5ly

I put 18 event handlers on a React element

Thomas Pikauli — Mon, 28 Jan 2019 12:29:39 +0000

If you've ever built a React app you've probably encountered a SyntheticEvent. Good chance it was onChange, but maybe you've been a little more adventurous and it was onKeyDown.

In a technical sense a syntheticEvent is a wrapper that's part of React. It takes the place of the native event handlers you might know from plain Javascript.

Let's say we have a <button /> and we want something to happen when a user clicks on it. In plain Javascript we would add onclick to the element. That doesn't work in React. Instead the library provides its own handlers which mimic the functionality and make them work equally across browsers. They look a lot like the native handlers though. For example: onclick in React is onClick.

You can always read more about them in the docs.

Fire 'm up!

Now we could go through the entire list of events and explain them one-by-one, but to really get a sense of what's going on when you add one of these handlers to an element, let's just hook them up.

I've picked 18 of them. There are more, but these are the most common ones. We're going to add them to an <input /> element.

Since the objective is to get a feel for them, let's try to answer two questions:

when do they fire?
how often do they fire?

The first question we're going to answer by giving a visual cue upon firing, and the second question can be answered by keeping a log. Let's start building.

A synthetic event handler accepts a function. So we're going to add a function to all 18 handlers.



<input
  onCopy={() => this.addEvent("onCopy")}
  onCut={() => this.addEvent("onCut")}
  onPaste={() => this.addEvent("onPaste")}
  onKeyDown={() => this.addEvent("onKeyDown")}
  onKeyPress={() => this.addEvent("onKeyPress")}
  onKeyUp={() => this.addEvent("onKeyUp")}
  onFocus={() => this.addEvent("onFocus")}
  onBlur={() => this.addEvent("onBlur")}
  onChange={() => this.addEvent("onChange")}
  onClick={() => this.addEvent("onClick")}
  onDoubleClick={() => this.addEvent("onDoubleClick")}
  onMouseDown={() => this.addEvent("onMouseDown")}
  onMouseEnter={() => this.addEvent("onMouseEnter")}
  onMouseLeave={() => this.addEvent("onMouseLeave")}
  onMouseMove={() => this.addEvent("onMouseMove")}
  onMouseOver={() => this.addEvent("onMouseOver")}
  onMouseUp={() => this.addEvent("onMouseUp")}
  onSelect={() => this.addEvent("onSelect")}
/>

As you might notice there is an anonymous in-line function that actually calls the real this.addEvent function. We have to do this because we want to pass an argument into the function; the name of the event.

The next step is to write the actual addEvent function. Before we write it, let's remember what we need to do. We need a visual cue upon each triggering of an event and we need to keep a count of each event being triggered. Let's actually start with the latter to see how many events fire. That could affect our idea of what we want to happen with regards to the visual cues.

Keeping a log

Our log of counts is a piece of data that changes upon user input. That means we're going to use state. The specific data structure we'll use is an array with objects inside of them. Each object will represent each type of synthetic event, and will have both a name property and an amount property. It would look like this:



[{ name: "onChange", amount: 1 }, { name: "onClick", amount: 5 }]

Since we're starting out with an empty array without any counts, the first thing we need to do on each firing of the function is to check whether we need to add a new event to the array. If, however, we find that the event was already added to the array, we only need to increase the count.



addEvent = event => {
  const existingEvent = this.state.counts.filter(c => c.name === event)[0];
  const amount = existingEvent ? existingEvent.amount + 1 : 1;
  const count = this.state.counts.map(c => c.name).includes(event)
    ? Object.assign({}, existingEvent, { amount })
    : { name: event, amount };
};

So the existingEvent will either contain data or remain empty. With that info we can determine the amount property. And finally we either have to update the existing object, or prepare a new one.

With that in place we need to update the state. Since our counts data is an array, and we now have an object, we need to either find and replace an existing object, or just tag the new object onto the array.



  const counts = produce(this.state.counts, draftState => {
    if (existingEvent) {
      const index = this.state.counts.findIndex(c => c.name === event);
      draftState[index] = count;
    } else {
      draftState.push(count);
    }
  });

  this.setState({counts})

Now you might see an unfamiliar function here: produce. This is not a function I wrote myself, but one I exported from a library called immer. I highly recommend you check out that library if you are in the business of mutating data, but love your immutable data structures. immer allows you to work with your data as if you were directly mutating it, but via a 'draft state' keeps both your old and new state separated.

With that in place we now have a new version of our counts state we can put in the place of the current version of our counts state. The only thing that's left to do is to render this data onto the page, so we can actually see the counts.

In our render() function we can map our counts array into a list.



const counts = this.state.counts.map(c => {
  return (
    <li key={c.name}>
       {c.name} <strong>{c.amount}</strong>
    </li>
  );
});

And in our return we can add the items to our <ul />.



 <ul>{counts}</ul>

Now we should be able to see our synthetic events pop up with their respective counts. Try and see if you can fire up all 18 of them.

You might notice that events like onMouseMove fire up way more than others. This informs us that for our visual cues we have to be a bit mindful about that. And speaking about visual cues, let's set them up.

Party time

My idea is to render the name of the event on a random position on the screen on each trigger, and make it disappear again after a second or two. To make it a bit more clear which events fires, we will add specific styling for each event. Let's do that part first.



function getStyle(event) {
  let style;
  switch (event) {
    case "onCopy":
      style = {
        fontFamily: "Times New Roman",
        fontSize: 50,
        color: "red"
      };
      break;
    case "onCut":
      style = {
        fontFamily: "Tahoma",
        fontSize: 40,
        color: "blue"
      };
      break;
    case "onPaste":
      style = {
        fontFamily: "Arial",
        fontSize: 45,
        color: "salmon"
      };
      break;
  }
  return style;
}

For reasons of brevity, these are not all 18 cases. You can find those in the full code, but you'll get the gist of it. Based on the event, we return a style object with a unique font size, font family and color.

The next part is to get the random position on the screen.



function getRandomNumber(min, max) {
  return Math.random() * (max - min) + min;
}

function getPosition() {
  return {
    left: getRandomNumber(0, window.innerWidth - 120),
    top: getRandomNumber(0, window.innerHeight - 120)
  };
}

The getPosition function returns a style object with a random number between 0 and the width or height of the screen. I've deducted 120 pixels, so the events don't fall of the screen.

With these helpers in place, let's think about how to actually make the events show up on our screen. We have already implemented the counts so we have a bit of an idea how to do this. The difference is that this time we want to save each event as a separate object we can render on the screen, only to get rid of that object after 2 seconds of time. That means for each event we need to update the state twice.

Let's start with updating the state just once.



  const id = shortId.generate();
  const position = getPosition();
  const style = getStyle(event);
  const events = [...this.state.events, { id, event, position, style }];

We first generate a unique id for each event using the shortid library. The reason for this, is that we need to be able to find the event again after it has been added to the state, so we can remove it.

Next we get our position and style object, which we'll need later to render the events on the screen. Finally, we create a new version of our events state.

If we update our state now and keep triggering events, we're going to get a huge array full of events, which will clog up the screen. So, we need to constantly clean up the array. How to do that?

An effective trick is to use setTimeOut, which is a little timer. After each update we wait 2 seconds, grab the id of the event we just added, and remove it again.



 this.setState({ events }, () => {
   setTimeout(() => {
     const events = this.state.events.filter(e => e.id !== id);
     this.setState({ events });
   }, 2000);
 });

We start out with our regular setState in which we update the events array we just created. But then as a second argument we add a new anonymous function. By doing this in the second argument of setState we ensure the initial update of events has been applied.

Within that callback function, we set our timeout to 2 seconds, and create an updated version of our events with the now updated state. Since we are still in the same addEvent function, we know the id and we can easily filter it out. Then we set our state for the second time.

Now if we were to log this.state.events we should see it fill up and empty out. But it's more fun to see that on our screen. After all, we have a style object with random positions and unique formatting. So let's do a .map again in our component and see how it turned out.



const events = this.state.events.map(event => {
  return (
    <div
      key={event.id}
      style={{
        position: "absolute",
        left: event.position.left,
        top: event.position.top,
        zIndex: -1,
        opacity: 0.5,
        ...event.style
        }}
     >
      {event.event}
     </div>
   );
});

As you can see we both add the position and styling of each event object to the element. We now only have to add the events variable to our return.

And with that we now have a nice synthetic event party on our screen. Aside from the visual fun we have just created, I hope you also get a feel for when each event triggers. Not each event will be super relevant in your day-to-day work, but sometimes it can be useful to know when onMouseLeave fires or just be aware that onDoubleClick exists.

See the full code in action here. Happy to chat on Twitter

What goes through my mind while writing a function 😵

Thomas Pikauli — Wed, 23 Jan 2019 17:35:42 +0000

I don't think a week goes by without me writing a function. Often simple handlers to modify a piece of state or format a bit of data. Sometimes something more involved, and occasionally up to the point I feel like my head is about to explode.

I've written one-liners, hundred-liners and probably way-too-many-liners. But no matter how many times I do it... each time I write a function, I keep stumbling upon so many questions.

For starters: do I need to write this function at all, or might I have a helper laying around that pretty much already does what I need?

As apps grow, there's a big chance the functionality you seek is already (partly) there. Either through your own great work or through a library that hides somewhere in your package.json.

But maybe it's not there, or you feel you can do a better job. And you promise yourself you'll create the one function to rule them all... Often for me it goes a little like this...

Do I begin with a test? The internet tells me to work test-driven. And to be fair, they make great points. Still, I might lose the energy and momentum I have. Because if I have to write a test, I would need a few moments to think and recalibrate my mind to think in tests.

We only want the pure stuff

Okay, let's forget the test for a moment... I can do that later. Do I make my function pure? That would be for the best right. It will help when I am going to write the tests, and maybe I could even reuse the function somewhere else.

But now I am writing the function I notice myself referring to this.state and this.props. It just quickens everything, and you know what, I can always fix that later.

I even find myself using new Date(). Okay, let's take a little break.
Maybe I can cut up the function in smaller pieces. Some of the stuff I'm writing can be pure and modular, while the rest of the function can be a bit like an impure container giving out the orders. That seems good.

Now I'm starting to get really smart. I have smaller functions calling each other returning beautiful predictable results. I write a few unit tests for them... I am on a roll. Let's try and get even smarter. I remember I have a few other functions in the app that will definitely benefit from some of the stuff I have just written.

Enter the genius

Let's hook those up to my small functions and start abstracting!

...abstracting
...abstracting
...abstracting

I am done and feel exhausted. Great work right! Right...? Or was I being too smart?

Suddenly I remember that some of the extra functionality I just hooked up might be revised in the near future. I definitely heard the others talk about that. Does that mean I have to edit my abstractions? Exceptions in abstractions. I know I don't like those.

Already I'm getting nightmares of code that's so sophisticated I don't understand it anymore. How will I delete that one piece of functionality that no one ended up using, but is now tied up into all my genius?

I revert like a madman and am back to my one single function. Duplicated logic means less dependency and easier deletion. Travel light, right? That's what were going for!

Doubt creeps up

But then again... what if this very simple piece of logic that's spread across the app in three different shapes needs an update because we decide to do things a little different with the app. Am I not going to miss one place where I should update it?

Again, the questions and scenarios keep coming up.

Unlucky for me, the future doesn't reveal itself. What I prepare for might not happen, and what I think will get back to later, could become the problem of another person.

So I remain with a lot of questions. I decide to write the function step-by-step, documenting my choices. I try to be aware of the context, but don't let it cripple me. It won't be perfect, but that's fine. Non-perfect code is easier to replace or delete. Let's just aim for what works and what is understandable. We make progress, and we try to have fun with it.

Let's upgrade our little audio player in React

Thomas Pikauli — Sat, 19 Jan 2019 13:05:53 +0000

This is a bit of a part two. So if you missed part one, have a gander!

Let's make a little audio player in React

Thomas Pikauli ・ Jan 12 '19

#react #audio #javascript #html

In this session we're going to add a skip and back button to our little player. Also we're going to make a visual time indicator and a way to jump to a position in the track. This will require a bit of styling. I tried to keep it to a minimum so we can focus on the Javascript, but yes, we'll do some CSS.

I chose to just use a regular stylesheet and no specific library for the styling. Personally, I love CSS-in-JS solutions – they just feel right – but they are heavily contested. Since we'll just use barely enough styling to get by, let's not get into those discussions and just use whatever Create React App gave us.

In part one we did most of the wiring up. In this sequel we'll do a bit more logic. Let's start with the skip and back buttons. First we'll add the buttons to our JSX and clean up a bit of the logic.

{this.state.player !== "stopped" && (
    <div className="buttons">
      <button onClick={() => this.handleSkip("previous")}>Previous</button>
      {this.state.player === "paused" && (
        <button onClick={() => this.setState({ player: "playing" })}>
          Play
        </button>
      )}
      {this.state.player === "playing" && (
        <button onClick={() => this.setState({ player: "paused" })}>
          Pause
        </button>
      )}
      <button onClick={() => this.setState({ player: "stopped" })}>Stop</button>
      <button onClick={() => this.handleSkip("next")}>Skip</button>
    </div>
  );
}

I've also added an onClick handler to the new buttons. You can see it calls the handleSkip function and expects an argument. In this case the direction: 'forward' or 'back'. Next we'll add the handleSkip function itself. Before we write it though, I've moved the array with our tracks to a constant at the top of our file. This is just static data that doesn't change.

const TRACKS = [
  { id: 1, title: "Campfire Story" },
  { id: 2, title: "Booting Up" }
];

For the function itself we have to figure out a few things:

the index of the track that's currently playing
the next or previous track based on the argument we received
what we're going to do when there is no previous or next track!

Let's start with the easiest thing. We have our array with all the tracks that could possibly be playing at this moment, and we also have a piece of state which should contain the title of the track that is currently playing. That's enough to make use of the findIndex method.

When using this method you get a number in return. Either it will be the index of the song we need, or it will be -1 aka "we didn't find what you we're looking for, sorry". Before we 'calculate' the next or previous track, we should really check how many tracks there are.

We can do that by grabbing the length of our TRACKS array and subtracting 1. Why subtract 1? Because the length number is the exact amount of items in the array, while the index actually starts at zero. So 2 is 1, and 1 is 0. Hope that makes sense.

We've got two values now: the currentTrackIndex and the tracksAmount. That's enough to write the following logic.

handleSkip = direction => {
   const currentTrackIndex = TRACKS.findIndex(
     track => track.title === this.state.selectedTrack
   );
   const tracksAmount = TRACKS.length - 1;
   if (direction === "previous") {
     const previousTrack =
       currentTrackIndex === 0 ? tracksAmount : currentTrackIndex - 1;
     const trackToPlay = TRACKS[previousTrack];
     this.setState({ selectedTrack: trackToPlay.title });
   } else if (direction === "next") {
     const nextTrack =
       currentTrackIndex === tracksAmount ? 0 : currentTrackIndex + 1;
     const trackToPlay = TRACKS[nextTrack];
     this.setState({ selectedTrack: trackToPlay.title, duration: null });
   }
};

If you've read or tried the code, you might have deduced how we handle the third thing we had to figure out: what we're going to do when there is no previous or next track. We're actually just going to play the first track when there is no next track, and play the last track when there is no previous track. That was a personal choice by me. We could've disabled the skip buttons too. Or hide them. But I didn't feel like that.

Anyway. With our buttons working, we can now focus on creating a time indicator. We're going to set up a new component for this, which we'll call TimeBar.

<TimeBar
  setTime={this.setTime}
  currentTime={this.state.currentTime}
  duration={this.state.duration}
/>

As you might see it takes three props: a function to set the time of the track, the current time of the track and the full duration of the track. The current time and duration we already set up in the previous article, so we only have to make a function for setting the time of a track to a specific point. This is actually not too difficult.

  setTime = time => {
    this.player.currentTime = time;
  };

The function receives a value I called time. Then we access our player using the ref we placed in our earlier session. The player has value called currentTime we can mutate to the value we received into our function. That is all really.

Now for the component itself. Let's think a bit about what it should do. It needs to visually show how long the track is. It then needs to visually show where the track is. And finally you should be able to click anywhere on the bar to jump to that position in the song.

We're going to do this all in pure React, we're going to use my favorite Javascript method .map, and a lovely oldskool while loop. Let me show you the first bit, so we can talk about it.

function TimeBar({ currentTime, duration, setTime }) {
  const sBits = [];
  let count = 0;
  while (count < duration) {
    sBits.push(count);
    count++;
  }

  return <div className="timebar" />;
}

In React you can just use a function as a component. The props you've passed it enter the scene as arguments you can destructure. It's quite neat. Now for the first bit of logic. Why is it there, and what does it do?

Well, let's put on our thinking hats again for a minute and try to visualize in our mind's eye how we can display the duration (which is just a number) as a graphical bar consisting of bits of time. We can only do that if we turn the number into bits first. Luckily someone came up with the concept of seconds and even more lucky: the duration is also in seconds.

That means we can create an empty array and then start throwing our bits into it. We do that by starting a loop that will keep looping as long as our count is smaller than the duration. With each loop we add a number to our count, so we can be sure that at some point the count will become higher than the duration, effectively stopping our loop.

If all went correctly the loop should execute code for exactly the amount of full seconds there are in the duration. So we can fill our array with one bit on each turnover.

That's good. But how can we display those bits to become a bar. And let's just get ambitious. How can we make it so that we see the actual time of the track visualized on that bar?

const seconds = sBits.map(second => {
  return (
    <div
      key={second}
      style={{
        float: "left",
        cursor: "pointer",
        height: "30px",
        width: `${300 / Math.round(duration)}px`,
        background:
          currentTime && Math.round(currentTime) === second ? "white" : "black",
        transition: "all 0.5s ease-in-out"
      }}
    />
  );
});

There's a lot going on here. Let's digest it. The .map method allows us to take our array with seconds, and for each of those seconds return something of our liking. In our case, we're going to return a div, so that when placed next to each other, they form a nice horizontal bar.

The div has a key, which let's React keep track of which div is which. For that reason it has to be unique. All our seconds are different, so it's fine to use that for a key. Next we have our styling. The float makes sure the seconds are rendered side by side, but more interesting are the width and background.

Now you can't see this here, but in our CSS file I have decided that our timebar will be 300 pixels wide. This was an arbitrary choice, but one that affects the width of our seconds; we want all our seconds to be evenly spread across the bar. We can make that happen by calculating the width via a simple division. The Math.round is there to round the duration up to a whole number of seconds.

So we have a bar with divs evenly spread across its container each representing a second within the duration of the track. We also happen to have passed the current time of the track into our component. This piece of data is in seconds as well. Which is perfect. That means if we round it to whole seconds, we can match it to the seconds in our timebar.

Using a ternary operator we can compare our two values, and decide whether to render our div as white or black. With black being no match, and white being a match.

The result of our .map is saved to a variable I have called seconds. We only have to place that variable in the return of our component to make it render on the screen. As you might notice I have also added the formattedCurrentTime and formattedDuration to our return. These are the values we calculated in the first article.

return (
    <div className="timebar">
      <div className="bar">{seconds}</div>
      {currentTime ? (
        <div className="time">
          {formattedCurrentTime} / {formattedDuration}
        </div>
      ) : (
        ""
      )}
    </div>
  );

There a bunch of classNames in this snippet. And there are more in the full code. They refer to CSS. I won't lay them out here, instead you can check out the styles.css in this CodeSandBox . They help put everything in the correct place.

Depending on your creativity, determination and skill you can make something really nice out of it. Or at least something that's a bit more spectacular then what I have created. My excuse is of course that I wanted to focus on the Javascript 😅.

Anyway, that concludes the upgrade of our little player. Now let's play some music and enjoy our day.

Final addendum! What if our track is nicely playing, but it ends? What happens then? Surely it should play the next track right, if there is still one? I think so too. So let's quickly set it up, before I really let you go.

if (
      this.state.duration &&
      !isNaN(this.state.duration) &&
      this.state.duration === this.state.currentTime
    ) {
      const currentTrackIndex = TRACKS.findIndex(
        track => track.title === this.state.selectedTrack
      );
      const tracksAmount = TRACKS.length - 1;
      if (currentTrackIndex === tracksAmount) {
        this.setState({
          selectedTrack: null,
          player: "stopped",
          currentTime: null,
          duration: null
        });
      } else {
        this.handleSkip("next");
      }
    }

The above code is part of the componentDidUpdate lifecycle. It check to see if there is currently a duration and if that duration is equal to the current time of the track.

If that is the case it would mean the track has ended. We then do a quick check to see if this was the last track of our playlist, or if that there is still another one to be played. If this was really it, then we set all our state back to default. If there is still a next track, then we just simply call the handleSkip function we created earlier.

That's really it for now!

Fading in a video background in React is fun!

Thomas Pikauli — Thu, 17 Jan 2019 16:45:30 +0000

Using a video as a background is fun. It allows for captivating website design. Unfortunately videos are on the heavy side of the MB spectrum, which means they take a bit more time to load than your HTML, Javascript and CSS. As a result the video might suddenly pop up in the background after your visitor already has settled into the website, slightly ruining the elegant effect it's supposed to have. To solve this we can use a short fade-in on the video.

To fully appreciate the effect, see it live in action here

We're going to do this in React, since Gatsby is quite popular (rightfully so), but it shouldn't be much more difficult in plain Javascript; if not easier. Let's start with the video itself. If you have a React component, you can drop in the video tags in your JSX.



class MyCoolWebsite extends React.Component {
  render() {
    return (
      <video
        autoPlay
        muted
        loop
        style={{
          position: "fixed",
          width: "100%",
          left: 0,
          top: 0
        }}
      >
        <source src="urlOfMyVideo.mp4" type="video/mp4" />
      </video>
    );
  }
}

You might notice I added a bit of inline-styling to make the video appear across the entirety of the screen. You can change this styling to whatever fits for you. Also there are a few video attributes, which respectively make the video play automatically, mute the sound the video might have, and loop it into eternity. Next up we add a ref on the video element.



    return (
      <video
        ref={ref => (this.video = ref)}
        autoPlay
        muted
        loop
        style={{
          position: "fixed",
          width: "100%",
          left: 0,
          top: 0
        }}
      >
        <source src="urlOfMyVideo.mp4" type="video/mp4" />
      </video>
    );

The thinking here is that once the component is mounted, the video is going to start loading, which means we somehow need to hook into that process. The ref we just placed helps us with that. We can access it, and then we can add an event listener to it.



  componentDidMount() {
    if (this.video) {
      this.video.addEventListener("loadeddata", () => {
        // execute code here
      });
    }
  }

  componentWillUnmount() {
    if (this.video) {
      this.video.removeEventListener("loadeddata", () => {
      });
    }
  }

This specific listener will execute a piece of code after the video has loaded, which is exactly what we need. And just to keep things neat and clean, we also remove the event listener once we don't need the component anymore.

Now for the fade-in itself. The way we will set this up, is by using a bit of CSS that changes upon the video being done loading. To be more specific, we will initially set the video to an opacity of 0, and then once it's done loading, we'll set the opacity to the default of 1. The transition property will turn this into a slow fade (depending on how many seconds you set it).

But before we do that, we first need to make our styling aware of the loading being done. We can utilize state for that. As you hopefully remember, we just set up an event listener. In that listener we're going to change our default loading state which I had set to true.



  state = {
    loading: true
  };
  componentDidMount() {
    if (this.video) {
      this.video.addEventListener("loadeddata", () => {
        this.setState({ loading: false });
      });
    }
  }

With this in effect we can hook up the styling we just talked about. The most interesting part is obviously the opacity property, which has a ternary operator to dynamically change the opacity based on our component's state, which in turn reflects the video's loading state. I do hope that makes sense.



    return (
      <video
        autoPlay
        muted
        loop
        style={{
          position: "fixed",
          width: "100%",
          left: 0,
          top: 0,
          opacity: this.state.loading ? 0 : 1,
          transition: "opacity, 2s ease-in-out"
        }}
      >
        <source src="urlOfMyVideo.mp4" type="video/mp4" />
      </video>
    );

So with that in place we're about done. You can now set a regular background in your app, and then have the video background fade over that background after it has loaded. Quite a nice effect, I hope you make something beautiful with it!

When Javascript first clicked for me

Thomas Pikauli — Wed, 16 Jan 2019 10:30:47 +0000

I vividly remember a time before I knew how to write Javascript. I could do HTML and CSS, and maybe drop in the occasional JQuery snippet, but as soon as I saw variables or functions, I looked away in disgust. What was this unintelligible flurry of letters, symbols and numbers.

For years I ignored the hell out of it. And as long as my ambitions didn't surpass making a nice little website or setting up a blog, I was okay. There were a few times that a tutorial here or there lured me into stuff like Ruby on Rails or some other programming thing. But they usually scared me away as soon as they stopped describing every single thing I should do in absolute detail.

But I knew this behaviour could not go on. If I was serious about trying to make a living on the web, I should learn this Javascript language. If I really wanted to make an app, there was no going around it. So I made an ultimate attempt.

Me back when I tried to read programming books for the first time and I kept laughing very insecurely about all the 95% of text I didn't understand.

In reality this meant I did a combination of trying to read Javascript books (didn't click), reading blog posts (small click), watching a colleague of mine write advanced code (interesting, but no real click) and watching video tutorials (big click!).

For me the starting point of finally grasping what was going on was understanding the function. Somehow functions, arguments, parenthesis, parameters and returns confused me. How could that be, right? It's not like there are multiple ways to define a function...

But once I settled on manipulating my mind into thinking there is only one true way to define a function, I made a second mental step. I started to think about a function as a little set of instructions the browser carries out whenever you call it.

It made sense to me. And in the early phase of learning, that's really all that matters.The next question was what kind of instructions I could give to that function. And to whomst I would give those instructions.

Query selectors appeared to be part of the answer. It turned out (I think I saw this first in one of the Wes Bos videos), you could grab one of your HTML elements by their ID. You can then save that element as a variable, which you are very free to name how you want it.

But the real breakthrough happened when I learned about console.log and the browser console itself. I really can't overstate how important this revelation was to me.

Because now I could just trial-and-error things: hmm, now my variable is empty and now it has some sort of value. Just by being able to play around and get direct feedback I became able to predict what would happen when I did certain things.

And when you grasp just enough to get results, things start to become fun. So when I got my variables filled up, I was now ready to actually have my function do things with them. Manipulate their whole being, if you will.

That exact moment is when some bits of the reading I did crawled back into the forefront of mind. I could identify my variables held different types of data, and that based on that I could do different things. There were arrays, strings, numbers, etc.

All I had to do was console.log often enough and I could figure out with a bit of Googling what kind of methods were at my disposal. Not too say that all was well now in my mind or that I felt like a real programmer, but it was about the first time that I actually believed I could learn all this programming stuff. Or however I thought about programming back then.

It were those mental leaps that were necessary for me to not give up. Without any technical background the world of programming can be quite daunting, if only for all the lore and stigma that the word has. But when a couple things start to click, and you realize it's challenging, but not impossible, you can really start learning.

Now, when I speak to someone I never tell them that programming is hard or only for #thenerds. I always say it's just another skill you can learn. Like accounting, skateboarding or drawing. And if they are truly interested I refer them to YouTube. Just go watch people build things, explain things and see if that's something you want to do yourself.

In retrospect, it was watching videos of other people code that really helped me when I was still at the phase of being completely clueless. The combination of seeing the result of what someone was doing with live commentary was just super effective to me. Books and blogs only helped me at a later stage.

So this was the start of my grand journey. When did things first .click() for you?