Forem: James Foran

Vue Transition Group: Strange Entry behaviour

James Foran — Wed, 09 Dec 2020 10:17:06 +0000

While working with Vue's transition-group API today I was getting a strange entry motion on an element which I was adding to a transition-group. It seemed to be entering from the top-left of the screen when the item was added, however, it would leave the screen as I was expecting it too (as per the CSS which is shown later).

The below codepen demonstrates the behaviour I was experiencing...

Hit "Pull the trigger" to see the behaviour. The second red circle flies in from the left, rather than sliding in from the right!

My CSS is set to bring the second circle in from the right, and have it leave to the right once it's removed:

.smoothFlex-enter,
.smoothFlex-leave-to {
  transform: translateX(100px);
  opacity: 0;
}

It appeared as if the smoothFlex-enter class was not being applied to the element at the start of the animation, causing it to fly in from afar!

On further inspection via the dev tools, I noticed that after the element had been "removed" from the list, remained with an inline style of display:none.

<div class="circle smoothFlex-enter-to smoothFlex-move" style="display: none;"></div>

The above inline Style is added by Vue when the v-show directive evaluates to false. I was hopeful now that I had found the issue... Switching to v-if resolved the issue immediately!

In the codepen above, select "fix me" to see the desired behaviour in action. This button just switches out the v-show example for a v-if example.

I hope you have found this post useful!

Head over and have a read of the Vue docs for more information on the transition-group API. It's pretty amazing, but as always, it can be quite frustrating when things don't work as expected!

Links

vue animations

Vue/Nuxt + ChakraUI: Tabs

James Foran — Mon, 07 Dec 2020 04:08:08 +0000

I have been working with Chakra UI Vue for several months. I am using Chakra in a side project to learn more about JAMStack and Vue/Nuxt. I am drawn to Chakra UI because of its practical set of components, and its focus on accessibility. This is the first article in a series I will be publishing about Vue and Chakra. I hope you enjoy!

One of the components I have been working with a lot is the tabs component. Tabs works well when presenting content. I have also been using it to driver high-level option selection for specific processes and user flows. Let's jump right in...

This post assumes you already have a Nuxt project setup with Chakra installed, as well as auto-imports enabled.

The standard way of setting up tabs using Chakra is using a parent c-tabs element, containing a single c-tab-list and single c-tab-panels element.

<c-box>
    <c-tabs>
        <c-tab-list>
        <c-tab>One</c-tab>
        <c-tab>Two</c-tab>
        <c-tab>Three</c-tab>
        </c-tab-list>
        <c-tab-panels>
        <c-tab-panel>
            <p>one!</p>
        </c-tab-panel>
        <c-tab-panel>
            <p>two!</p>
        </c-tab-panel>
        <c-tab-panel>
            <p>three!</p>
        </c-tab-panel>
        </c-tab-panels>
    </c-tabs>
</c-box>

It is important to ensure you have the same number of c-tab-panel elements as you do c-tab elements. Not doing so may mean your content is not accessible to the user. The order is also critical to this working, as the first c-tab button will correspond to the first c-tab-panel element. This is quick to get up and running. Note, each c-tab becomes a button when it renders.

In addition to the separation of content, I also want to know which tab a user has selected. To do this I recommend moving to a different pattern. This pattern involves moving the tab options to an array and then using Vues v-for directive look to generate the c-tab-list elements.

<c-box>
    <c-tabs>
        <c-tab-list>
        <c-tab v-for="tab in tabs" :key="tab">{{
            tab
          }}</c-tab>
        </c-tab-list>
...
    </c-tabs>
</c-box>

We have now introduced a new data object here.. tabs. Lets set it up so the above code works:

data() {
    return {
      tabs: ['One', 'Two', 'Three'],
      tabIndex: 0,
    }
  },

We then call a method on the @change event, to change the tabIndex value:

 <c-tabs @change="setTabIndex">
     <c-tab-list>...

...
methods: {
    setTabIndex(index) {
      this.tabIndex = index
    },
}

As things are now, tabIndex will change as the user selects a different tab, but we don't yet know which option the user has selected, just its index value. To may the index value, back to the array, we then use a computed property to give us the selected tab text:

computed: {
    selectedTab() {
      return this.tabs[this.tabIndex]
    },
}

We now have the selectedTab, and tabIndex values in the parent component, which we can used to drive other behaviour.

For one final feature, we can then drive the default index, property in the c-tabs element using the tabIndex field:

<c-tabs :default-index="tabIndex" @change="setTabIndex" >

By doing this, you can set the initial tab selection.

Limitations of this approach

Your c-tab styling needs to be simple. Adding images or icons to your tab may over-complicate things. When using library components like this, keep it simple.

Another limitation may present itself if you want to enable/disable a tab. In this case, the following pattern works better.

Alternative

To enable a single tab to be disabled, the following approach can be applied.

 <c-tab-list>
    <c-tab>{{ tabs[0] }}</c-tab>
    <c-tab :is-disabled="tabTwoDisabled">{{ tabs[1] }}</c-tab>
    <c-tab>{{ tabs[2] }}</c-tab>
 </c-tab-list>

data() {
    return {
      tabs: ['One', 'Two', 'Three'],
      tabIndex: 0,
      tabTwoDisabled: false,
    }
  },

This maintains the array of options, but gives the programmer the ability to enable/disable a single tab.

Summary

Chakra's tabs are a joy to work with, as long as you keep it simple. If you also want to know the current active tab, then the above pattern works well.

A tale of two database paradigms

James Foran — Tue, 08 Sep 2020 11:24:10 +0000

It was the best of times, it was the worst of times. It was the age of wisdom, it was the age of foolishness. And I need a database for my front end.

There are many solutions out there for this exact problem. Having worked with SQL databases for most of my career, I am very comfortable with relational databases, SQL scripts, PL/SQL, all that jazz. But the world of front end development is relatively new to me.

Currently I am developing a web application that will change the world! t the very least it is changing my perception of the world, and helping me learn the ins and outs of VueJS, Nuxt, Netlify functions, and now, databases for the front end!

Having recently done some prototyping with Netlify functions, I am really excited at the prospects of building out lambda functions using Node.js, to provide my frontend with the data it needs.

Perhaps suffering from shiny ball syndrome, I dove straight into FaunaDB. Initial prototyping did not even need netlify functions. I was able to get up and running with a noSQL database and GraphQL interface in one fell swoop. It really was quite a simple process, and the performance of my graphQL queries were fast, sub 100ms repeatedly. However, I quickly ran into some constraints, that I was not well equipped to overcome quickly.

My history of solving problems with SQL left me struggling with GraphQL as a way to access data. . I am used to being able to shape my data in an SQL script, and filter, manipulate, all in the one place. Working with GraphQL data I was really restricted with this way of thinking. Sticking with FaunaDB, I turned to the native Fauna Query Language. This was completely foreign to me, but I felt if I spent some time trying to learn it, I could really benefit.

FQL is a procedural language, while SQL is declarative. The procedural nature of FQL means that all the complexities of executing a query are front and centre when your write your very first query. Keen to learn though, I gave myself a weekend. My first target was to convert at simple SQL query, joining two tables(aka collections), and restrict the data based on a parameters in each table. In SQL, this is a 20 second query to write. This is something that cannot done in a GraphQL query, and as I found out, is not straight forward in FaunaDB either.

To do so, you have to create indexes on the data fields you want to query on, and the resulting FQL is really foreign to me. So foreign to me, I could not get my head around it in a weekend. At this point, I realised I was not yet ready for a dive into noSQL databases. They were really going to slow me down.

In the future, when I do have the time and/or the need for a noSQL database, I think I will start with dynamodbbook. There is a great podcast interview with the author of the book Alex DeBrie on Sofware Engineering Daily podcast.

So, I began to look elsewhere. What were others doing in the JAMStack space? At the time #RedwoodJS was being launched, and Tom Preston-Warner was doing the rounds on many of the JS podcasts I listen to. They too had decided to steer away from FaunaDB, and were instead building their full stack JAMStack using postgres and Prisma.io.

Postgres, an SQL database... now that is a language I am familiar with... and open source also. But what is Prisma.io? I decided to find out if it could give me what I needed in my Netlify functions...

So away I went, starting with my familiar SQL database table creation. Comparing this process alone to working with FaunaDB, I would say the process of generating a FaunaDB GraphQL schema is actually easier, and a bit more streamline, however, its the next step that really blew my mind with Prisma.io...

Different to many of the ORM's the Prisma CLI has a function call introspect. This basically looks at your database, and automatically builds the application model. From here, you need to execute a second function (what a pain!) call generate and you are ready to go.

The generate command, and I will take this straight from the prisma.io documentation, "provides a programmatic and type-safe API to read and write data in the shape of your application models".

Within a few hours, I was already feeling very comfortable with the API's, and actually felt quite powerful. The API's are a direct match for the relational data models, and I am able to do most things I can do using SQL, however, I am using JavaScript, and benefiting from the type-safe API's at the same time. And if i run into limitations, I can simply write an SQL Script, and execute it using a Prisma API

So, for now, I think I will stay in the familiar city of SQL.. I am still really keen to learn more about noSQL, and FaunaDB. I biggest hope for FaunaDB is that they come up with an API similar to prisma, which abstracts away come of the complexities of FQL. SQL is on the road-map for FaunaDB.. I will definitely be watching this space.

Perfect Documentation

James Foran — Wed, 02 Sep 2020 02:58:00 +0000

So you have taken the bait. Documentation really is the hottest topic in tech right now 😼.

This post is inspired by the podcast Enjoy the Vue where they discussed in detail the documentation process. Check out [episode 30(https://enjoythevue.io/episodes/30) for all the gory details! Thanks Natalia and Sam and the rest of the team at Enjoy the Vue! Now lets dig in to this very high level process 😜.

The Process

Crap Documentation (docs)

You have to start somewhere.. and documentation will always be less than ideal to begin with. There are no shortcuts too good documentation either. Don't expect your first draft to be close to good. Just do it.

Review

After you have completed your personal review, you need the documentation to be reviewed by others. This will include SME's (subject matter experts) and people who represent the intended audience. If you don't have people available to review it, publish it. You can then incorporate feedback from readers feedback.

Good Documentation

After many reviews, and feedback from readers, documentation can get to a good state. Be careful though, this will not last. As time passes, documentation can quickly become outdated, and will become crap documentation again in no time.

Perfect Documentation

While its an honorable goal, no documentation will ever be perfect. Maintaining good documentation is a lot of work in itself. But the benefits of maintaining good documentation are huge.

I think much of the success of VueJS today has to do with its great documentation. Yes, its great, and that is because there are so many contributors. Over 700 people have contributed to the Vue docs.

I think documentation can help in many ways. I also like to document stuff before I start developing in some cases too. It helps me to frame my thoughts, and keeps me focused if I get stuck on a technical issue that takes me down a rabbit 🐰 hole.

And, this document is in the "crap" phase itself. I would love for you to review it, and provide feedback below. Perhaps together we can make this process "good".

Netlify functions + custom Utils

James Foran — Tue, 01 Sep 2020 12:02:27 +0000

In the beginning

Earlier this year I started to experiment with Netlify Functions. I was really excited at how easy the whole process was. However, when I went to use them in a live project I immediately wanted to share some code between functions. Coming coding c++ in Arduino, this was pretty easy. I wanted a similar experience in Node.

Being new to Node and JavaScript, it took me some time to find the solution that I thought was right for this situation.

I will take you through the most basic example, starting with a clean slate. The following assumes you have node, npm, and netlify dev installed in your pc.

Firstly though, what do I want to achieve. For the project in question, I have several functions that make calls to the Strava API. As part of this, I need to refresh the token. This is not something I wanted to do in each function, so, I needed to create some shared functionality, to ensure my code is DRY.

Netlify functions, as simple as can be.

The following

First lets start a new project. Create a new project Directory. I have called mine
Create a netlify.toml file, and a functions directory within project.
Edit the netlify.toml file, and add the following lines
```
[build]
    functions = "functions"
```

create a hello-world.js file in the functions directory.

exports.handler = (event, context, callback) => {
    return {
      statusCode: 200,
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify('hello-world'),
    }
}

Lets test this quickly.

Note, I am using windows terminal with wsl2.
from the terminal of your project directory (not the function folder), run the command netlify dev. In a separate terminal, run netlify functions:invoke
Accept the prompts, and you should should now see the function execute. Here is what it looks like for me...

In the first terminal, we have the console.log outputs, and in the second, we have the message "hello-world".

Netlify functions + a utility node module

Hopefully this has all worked out so far for you. If not, keep trying! We are not going to move onto the tricky part, building a node module. Its easier than you might think.

There are options within NPM to publish a module, but I want to develop side by side for now. Instead, I will create a local 'node module', that we can utilise in our hello-world file.

create a utils folder, inside your functions folder.

create apackage.json file. This can be done manually, or by running npm init in the directory. Note the src/index.js

{
  "name": "utils",
  "version": "1.0.0",
  "description": "",
  "main": "src/index.js",
  "scripts": {
    "build": "npm run build"
  },
  "author": "james@flexion.tech",
  "license": "MIT"
}

Now create a src directory. Within that directory, create an index.js file.

Copy in the following code.

Note, we are just using CommonJS modules here.

module.exports.hello =  () => {
  console.trace()
  console.log("hello function")
  return "hello from utils"
}

module.exports.goodbye =  () => {
  console.trace()
  console.log("goodbye function")
  return "goodbye from utils"
}

Next, create a package.json file in the functions directory.. You can again use npm init as we did previously. The most important difference is the following addition:
```
  "dependencies": {
    "utils": "file:utils"
  },
```
We are almost ready to put our fuctions to use, but there is one important last step. From the functions folder, we have to now run npm install. This is a one time thing only.

Lets now update our hello-world.js file. One thing I like about this, is it does not expose the utility functions, and keeps everything in one place.

const utils = require('utils')
exports.handler = (event, context, callback) => {
  try {
    ...
    const message = {
      hello: utils.hello(),
      goodbye: utils.goodbye()
    }
    ...
    }
}

lets test
1. Make sure netlify Dev is running.
2. Lets run the function directly this time. this time run netlify functions:invoke hello-world --no-identity
Review the output. You should see the object displayed in the invoke window, and a console.trace output in Netlify Dev

that's a wrap...

Thanks for reading. If you found any mistakes, or have some further input, please let me know in the comments. There is also a repo on github if you want to check it out.