Forem: Ondrej Polesny

How To Check If Array Is Empty In TypeScript

Ondrej Polesny — Wed, 08 Dec 2021 09:12:06 +0000

When processing JSON responses in TypeScript, how do you safely check if a variable is an array and is not empty?

Let's say we get a response from an API (in this example, it's Kontent API):

const blogPosts: BlogPost[] = (await deliveryClient
  .items<BlogPost>()
  .type("blog_post")
  .toPromise())?.data?.items

We expect that response to be an array of BlogPost objects. Also, note the ?. notation that allows us to unwind the response and select just the data we need. If the response doesn't have the expected format, we will get null instead of undefined error.

Therefore, we first need to check if the response is a defined array:

if (!Array.isArray(blogPosts)) {
  throw new Error("Response has a wrong format")
}

The Array.isArray function will catch all possible values:

// all these calls return false
Array.isArray(undefined)
Array.isArray(null)
Array.isArray({})

// DON'T DO THIS
// as there is no need for checking the variable separately
if (blogPosts && Array.isArray(blogPosts)) { }

// DO THIS
// Array.isArray() is doing the null and
// undefined check automatically
if (Array.isArray(blogPosts)){ }

Note: Check MDN Web Docs for more information.

Then, we check if the array contains any items via .length property:

if (blogPosts.length == 0) {
  throw new Error("Response contains no items")
}

And that's it. 💪

The full code looks like this:

const blogPosts: BlogPost[] = (await deliveryClient
  .items<BlogPost>()
  .type("blog_post")
  .toPromise())?.data?.items

if (!Array.isArray(blogPosts) || blogPosts.length == 0){
  throw new Error("No data")
}

// all good here
console.log(blogPosts)

You can also wrap the code in try/catch block to make sure you also catch errors from network communication.

If you need any help with processing your Kontent data, join our Discord! 😎

Kontent Horizons developers news flash

Ondrej Polesny — Tue, 09 Nov 2021 08:25:12 +0000

Hey developers, thank you for attending Kontent Horizons! If you’re excited about our updates, find more information about them below or get in touch with us on Discord

Documentation

New streamlined overview of tech stacks

JavaScript + TypeScript

.NET

Nuxt 3

Discord

Join us on Discord to discuss other topics, like GraphQL :-)

What Gatsby v4 brings to your static site?

Ondrej Polesny — Tue, 21 Sep 2021 15:11:33 +0000

The new version of Gatsby is available in beta and brings many improvements. How are they going to affect you and the development and maintenance of your sites?

In this article, I summarize the key new features that Gatsby v4 brings and explain how each of them will affect your daily work with a Gatsby site.

Gatsby v4 Improvements

Gatsby v4 was officially introduced and made available as a public beta last week during Gatsby Camp and it brought major updates:

New rendering modes for pages
Parallel query processing
Improved Gatsby Cloud preview

Let's start with the first and see what changes for you.

New rendering modes for pages

Gatsby introduced support for two additional modes and now lets you use:

SSG - static site generation = pages generated during a build
DSG - deferred static generation
SSR - server-side rendered

SSG is the original concept of static site generators, so let's start with the second one - the deferred static generation. It's not a new concept. We've been successfully using it with Next.js and Netlify had already introduced a similar improvement for other static site generators with their Distributed Persistent Rendering and On-Demand Builders. The idea is, you pre-build only the core parts of a large site and leave the rest to be generated and cached (stored) only after the server receives a request for a specific page from the first visitor. In other words, on-demand.

Having DSG now available in Gatsby is definitely a great improvement. In the past, it was challenging to use Gatsby for large sites as the build times grew with content significantly. Now, with DSG and Server-Side-Rendering mode (that we all saw coming with the introduction of serverless functions this spring), you now get full control over how each page of your site gets rendered.

However, there is one downside. From my experience, Gatsby is often used by beginners. Don't get me wrong - many of them are experienced developers, just not with JavaScript. And what they value the most is the low entry barrier. They could get a site up and running very quickly, they didn't have to read any docs as the GraphQL data sourcing allowed them to see every content that's available, and for anything extra, there was always a plugin.

While all of that is still true, the added rendering modes (SSR, DSG) require developers to make informed decisions that require them to learn more. The time they need to invest to see their new site live increases. And the same applies to onboarding developers.

Now, you may argue here that they would need to learn that with any framework anyway and that's true. But Gatsby, until now, was a perfect stepping stone into Jamstack on React. Just like Gridsome is on Vue. I've seen many agencies tipping their toe in the Jamstack water with Gatsby and the low entry barrier was the biggest attraction for them.

Note: See the full explanation of Gatsby's rendering modes in this video or in their docs.

Parallel query processing

Another great improvement towards decreasing the build time. It's actually not optimizing the build but distributes the computation of page queries to multiple processor cores that work in parallel. The Gatsby team made this possible by moving the content from the Redux store to LMDB that supports concurrent access. So we're getting better build time by efficiently using the hardware. Good thing is, you don't need to take any action besides upgrading to the newest version of Gatsby.

Gatsby Cloud preview update

If you saw my talk at Gatsby Conf this spring, you know that editors expect their CMS to generate previews of their content and they expect it to do it instantly. With Gatsby, this was made possible with incremental builds that took only a few seconds. Now, the Gatsby team took the preview experience on Gatsby Cloud one level further and implemented a UI panel that tells the editor in real-time that preview is coming.

Of course, apart from that, the Gatsby team is constantly working on differentiating Gatsby Cloud from other hosting platforms and now claims that it is capable of 10x faster deploys.

Kontent and Gatsby v4

If you're using Kontent by Kentico as a content source for your Gatsby site, you're probably using both of these packages:

Gatsby Source Kontent Plugin Plugin providing data from Kontent REST API to Gatsby GraphQL model.
Gatsby Kontent Components Package with React components that process Kontent data.

We've prepared the new source plugin version ahead of the Gatsby v4 beta release. However, it will be merged only after the v4 is fully released, so until then, make sure to check out this version of the source plugin.

The Gatsby Kontent Components package is fully compatible with both the current and the new versions of the source plugin.

Should I upgrade?

The presented changes have one thing in common - Gatsby is trying hard to enable large-scale applications. They constantly work on decreasing build times (which interestingly brought new potential with the move of the content store), providing options to avoid building everything, improving the Gatsby Cloud services, focusing more on the content editor experience, and working closely with strategic partners.

If your site runs on Gatsby, I'd encourage you to try out the new features as they solve the problems of the majority of sites.

Vue.js cheat sheet: Rendering data into HTML

Ondrej Polesny — Fri, 07 May 2021 20:14:44 +0000

Are you just starting out with Vue.js? Or has it been long since you’ve worked with Vue? This cheat sheet lists the nine most common tasks and solutions when outputting data to HTML.

In all these samples, the first part shows the syntax, and the second part shows the usage with real data.

Outputting data into HTML

The first test of your app or rendering data between HTML elements:

{{ variable }}
↓
{{ metadata.subtitle.value }}

Adding the standard class attribute

After testing the app, you want to make it look nice with styles:

<... class="classname">
↓
<div class="sidebar__inner">

Outputting data into HTML attributes

When adding links or rendering images with alt tags, this is how you can fill the elements’ attributes:

< ... :name="variable">
↓
<a :href="`https://twitter.com/${author.twitter.value}`">

Outputting HTML

In certain cases, like when consuming rich texts from a headless CMS, you need to render already formatted HTML:

< ... v-html="variable"></...>
↓
<div v-html="article.teaser"></div>

Iterating over data sets

Iterating is useful for creating lists of items, like index pages of blogs or product catalogs:

< ... v-for="item in collectionVariable" :key="item.uniqueKey">
↓
<article v-for="article in articles" :key="article.id" ... >

Iterating over data sets with index

The same use case as before, but this way, you can access an index of each item:

< ... v-for="(item, index) in collectionVariable" :key="item.id">
↓
<article v-for="(article, index) in articles" :key="article.id" ... >

Rendering conditional markup

Conditions allow you to hide or display specific parts of markup based on data:

<... v-if="variable !== null">
↓
<div v-if="data.length > 0"> ... </div>

Rendering conditional markup including else branch

They can also be used to display preloaders in case of async data fetching to let your visitors know that something is happening:

<... v-if="variable !== null"> ...
<... v-else>
↓
<div v-if="data.length > 0"> ... </div>
<div v-else>Loading...</div>

Passing data to child components

When you start using components, this is how you can provide them with data from the parent:

<component :componentVariable="variable">
↓
<links :author="author">

You can also download this cheat sheet in printable form and check out its alternatives for React and Angular.

Animating multiple elements with Vue transitions (and CSS var() function)

Ondrej Polesny — Thu, 29 Apr 2021 18:06:49 +0000

Transitions are a great way to make your app interactive. Vue.js allows us to animate any dynamic events on elements with the <transition> component. But what if you need to animate multiple elements that are related to each other?

TLDR: CodePen link

I stumbled upon this problem when I wanted to animate graph bars. Each bar needed to have a specific width and had to be animated right after the previous one. Also, I did not want to hardcode the number of bars, so it all needed to be data-driven.

Building the data and template

So let's isolate the problem, this is how the bars are defined in a Vue app:



data(){
  return {
    bars: [75, 50, 100]
  }
}

And they are rendered in a for loop:



<div v-for="(bar, i) in bars" :key="i" class="bar">{{bar}}%</div>

Animating the bars using

The first step in animating them is to add a component and a single root as that's what Vue requires:



<transition name="bars" appear>
  <div>
    <div v-for="(bar, i) in bars" :key="i" class="bar">{{bar}}%</div>
  </div>
</transition>

Note the appear attribute. It instructs Vue to animate the first (and only) child element when it appears in the DOM. Vue is clever enough to search the applied styles for transition and it will add a few special classes to the element for the duration of the transition:

bars-enter-active for the whole duration
bars-enter-from at the start to define CSS to animate from, e.g. width: 0
bars-enter-to at the end to define CSS to animate to, e.g. width: 75%

The problem is, we need to define these properties on a more granular level - for each bar.

Connecting data with CSS using var()

The CSS var() function allows us to nicely connect dynamic data with CSS. We configure the data just like any other style definition of the element:



<div style="--variableName: variableValue"></div>

And use var(variableName) in the actual stylesheet:



.selector {
  CSS property: var(--variableName);
}

In this case, we'll need each bar to define its width and calculate the animation delay using the item's index:



<div v-for="(bar, i) in bars" :key="i" class="bar" :style="`--width: ${bar}%; --delay: ${i}s`">{{bar}}%</div>

And add the accompanying styles:



.bar {
  width: var(--width);
}

.bars-enter-from .bar {
  width: 0;
}

.bars-enter-active .bar {
  transition: all 2s;
  transition-delay: var(--delay);
}

The last thing to keep in mind is that Vue will only keep the special CSS classes on the root element for the amount of time defined in its transition. So let's add the expected animation time as transition duration:



<div style="`transition: all ${(bars.length-1)+2}s`">

The animation will take exactly N+2 seconds if N is the number of bars and each bar takes 2s to render. If you set it to a lower value than needed, the animation of some bars will not finish and just skip to the final position.

See the functional sample on CodePen.

Conclusion

The combination of --variableName: variableValue and var(--variableName) is a nice way to avoid generating too many style definitions (that are even then limited) through for loops.

If you want to share your experience or get in touch, join the Kontent Discord and ping me a message 😊

How to use Kontent Delivery SDK with native ESM and Vite

Ondrej Polesny — Wed, 31 Mar 2021 12:11:40 +0000

Why native ESM and Vite?

When working on JavaScript projects, we are used to bundling every bit of functionality into a JS bundle that is then served to all visitors of our sites. With native ESM we can get around the bundling and serve modular JS code to modern browsers directly and dynamically.

One of the tools that help us with this task is Vite. It effectively replaces Webpack and allows for instant cold-start of your development server as well as ensures optimal output for production. In turn, it asks for all code to be compatible with ES2015 and newer, so no CommonJS anymore.

If you try to build your site with Vite and your code does not comply, you will most likely see the following error:

❌ Uncaught ReferenceError: exports is not defined at ...

The error occurs after you generate the production build and comes from your Vite-optimized code bundle. It means there is some unsupported functionality left in your code or in the packages that you use.

The Kontent JS Delivery SDK may be one of them. To configure it to work with Vite you need to do the following:

Target ESNext version of the Delivery SDK

The Kontent JS Delivery SDK from version 10.4.1 comes with the ESNext version in a subfolder _esNext so you just need to ensure your code uses it. But to make it a bit more complicated, you also need to use _es2015 (the newest) version of kontent-core package that the kontent-delivery depends on.

So you see, you can't just adjust all your imports to use a subfolder _esNext. To solve this issue, you need to tell Vite to redirect all relevant imports to that specific subfolder. Vite passes this information to Rollup - the module bundler it uses internally. The vite.config.ts looks like this:

export default defineConfig({
  plugins: [vue()],
  resolve: {
    alias: {
      '@kentico/kontent-core': '@kentico/kontent-core/_es2015',
      '@kentico/kontent-delivery': '@kentico/kontent-delivery/_esNext'
    }
  }
})

We are redirecting all kontent-core and kontent-delivery imports to the respective subfolders.

Note: If you're not using Vite and need to do the same with Webpack, see this page in their docs.

Add BrowserRichTextParser to DeliveryClient config

The SDK may be used in both browser and Node environments. Because Node.js does not feature browser API, the SDK is capable of dynamically loading a (much larger) Node.js parser based on the runtime context. However, some compatibility issues with Angular required the use of CommonJS's require.

You're building a website, so you can get around this by defining the browser-specific parser in the DeliveryClient config:

import { BrowserRichTextParser } from '@kentico/kontent-delivery'

const client = new DeliveryClient({
      ...
      richTextParserAdapter: new BrowserRichTextParser()
    });

And that's it. You're good to go 🤗 Try npm run build and npm run serve and your console should be nice and clean.

If you're using only ES2015+ compatible packages, using Vite you can get a much better development experience with zero waits and more effective production bundles.

Follow my Twitter if you don't want to miss any new articles 🐤

How to use Highlight.js on a Next.js site

Ondrej Polesny — Mon, 16 Nov 2020 11:47:33 +0000

Is your blog built using Next.js and you want to use syntax highlighting on code samples? This short guide will show you how to plug Highlight.js into your Next.js site.

What is Highlight.js?

Highlight.js is a Javascript library that turns code samples into highlighted code. You can get the whole bundle from CDN and plug it into your website, however, it's rather large as it supports tens of programming languages including Javascript, C#, CSS, Ruby, PHP, and many more.

A better approach is to select only the languages you will need on your site. I'm using just Javascript bundle currently, but it's possible to have any combination that fits your programming interests and focus.

Highlight.js is activated when your site loads and adjusts the look and feel of your code samples using its own CSS.

How to use syntax highlighting on a Next.js site

Using Highlight.js on an HTML page is easy using global bundles. On a Next.js site built with React and JSX, it gets a bit more complicated.

Install Highlight.js

First, you need to install Highlight.js using Node:

npm i highlight.js

Then open the page you want to use code highlighting on. This would typically be a blog post template. First, add the stylesheet to your template markup:

<React.Fragment>
    <Head>
        ...
        <link rel="stylesheet" href="//cdn.jsdelivr.net/gh/highlightjs/cdn-release@10.3.2/build/styles/default.min.css"></link>
    </Head>
...
</React.Fragment>

You can also add the styles locally if you want to avoid using an external resource by importing them into your _app.tsx:

import 'highlight.js/styles/default.css';

Add your code samples into JSX

To add your code into JSX, follow this simple pattern:

<pre><code className="js">
{`
your code
`}
</code></pre>

As long as your code does not contain backticks, this will nicely escape all special characters. Take a look at this simple Javascript example:

<pre><code className="js">
{`fetch('{url}')
    .then(response => console.log(response));
`}
</code></pre>

The class name helps Highlight.js recognize the used programming language and adjust the highlighted color scheme.

Initialize Highlight.js

The final step is to plug Highlight.js in and let it scan and adjust all the code samples. Add the following code to the top of your template:

import hljs from 'highlight.js';
import javascript from 'highlight.js/lib/languages/javascript';
hljs.registerLanguage('javascript', javascript);

If you want to use multiple languages, repeat the bottom two lines for all of them.

Highlight.js needs to be activated when the page is rendered. You can use React Hooks to do so:

{
    ...
    useEffect(() => {
        hljs.initHighlighting();
    }, []);
    ...
    return (
        *JSX*
    )
}

And that's it 😊. Compile your site and check if syntax highlighting works.

Light & dark modes

If you're using multiple stylesheets on your site to adjust its colors, it's possible to also switch themes of syntax highlighting. Take a look at this project which contains stylesheets fitted for respective color schemes.

Conclusion

In this article, I showed you how to plug Highlight.js into your Next.js site. This approach can be also used on plain React sites or sites implemented using other static site generators like Gatsby. You can also check out the full implementation on my personal site on GitHub.

🤦‍♂️ How to fail to record a conference presentation

Ondrej Polesny — Tue, 10 Nov 2020 14:18:53 +0000

Last week I was recording a presentation for the conference Kontent Horizons. I did not want to just use a webcam and laptop mic, so I had borrowed a Sony Alpha II camera.

I cleaned up the stage, which means mess everywhere but where the camera looks, and used my wife as a model to set up the camera aperture and focal point. I even did a test video and everything looked good.

I changed the battery pack to get a nice hour of recording window and talked through the whole presentation. You know the feeling when you have all the footage you need? I had that, for about a minute.

I plugged the SD card into the computer only to find out that I am completely out of focus and the frame is missing a lot of light 😫. I ended up re-recording the next morning.

Lesson learned: The focal point of a camera may be reset if you exchange a battery pack. Always do a test video BEFORE recording a presentation.

Bonus: As I'm using my iPhone to record the sound from a clip-on mic, I also found out that if someone calls you in the middle of the recording, the phone stops recording. And you have no idea as it's on MUTE! There went another 45mins of my life 🥱. I hope the presentation will be worth it, it's about choosing the right Jamstack tool, and you can see it on Kontent Horizons for free 😊.

🎈 Weekly Win (44/2020)

Ondrej Polesny — Tue, 27 Oct 2020 09:49:13 +0000

Did you attend the Jamstackconf a few weeks ago? If you did, I hope you visited our virtual booth too. We had many interesting conversations and got to live coding too.

Around that time I have just finished my new personal site on Jamstack. You know, to have it nice and fast. But what I observed on other, mainly Gatsby-powered, sites were these nice transitions between pages. No visible flick and reload in the browser when navigating to other pages, but a seamless transition.

When we discussed that on Jamstackconf, there was a guest in our booth that encouraged me and helped me to do the same on my website using Framer Motion. It took literally just an hour including finding and fixing one bug in routing 😄

Take a look at ondrabus.com and if you like the transitions, add them to your website too: Framer Motion on Github.

🤦‍♂️ Weekly fail (40/2020)

Ondrej Polesny — Tue, 29 Sep 2020 08:05:53 +0000

Last few weeks I've been working on converting a Gatsby Lumen sample site to Gridsome during live YouTube streams. I stumbled upon a problem when resolving rich text data and images. The images were just not showing up.

So I used one of my innovation days to try and debug the Gridsome source plugin for Kontent. I succeeded in finding the issue! This made me so happy that I immediately wanted to add it as an issue to the plugin repository. So I opened the plugin repository on GitHub only to find out someone has already done that half a year ago. 🤦‍♂️

Lesson learned: Always check Issues on GitHub before debugging.

But I didn't let this fail win. I went ahead and posted a pull request with a workaround! 💪

🤦‍♂️ Weekly fail (37/2020)

Ondrej Polesny — Tue, 08 Sep 2020 11:10:14 +0000

Last week I was converting a Gatsby Lumen starter website to Gridsome and got stuck on an error
Error: Cannot get field 'id' from type 'Page'. Field does not exist.

The error occurred only in case a certain page was published in the headless CMS Kentico Kontent and it was happening in the GraphQL schema generation. So it was quite difficult to debug.

I tried the try/fail method of debugging only to find out you can't use "Page" as a type name for your nodes. Not sure what the reason is as I was not willing to keep digging after several hours of nail-biting.

Lesson learned: Sometimes the tools we use don't have everything documented. If you're experiencing the above error, add a prefix to content item types in the configuration of the Gridsome Kontent plugin:

options: {
  ...
  contentItemConfig: {
    contentItemTypeNamePrefix: '_',
    ...
  }
}

🤦‍♂️ Weekly fail (35/2020)

Ondrej Polesny — Tue, 25 Aug 2020 09:35:02 +0000

While working on the styles of my site, I decided to hide a background video for mobile devices (bandwidth reasons). The video was placed in a wrapper to ensure it always occupies the whole available space.

The problem was that later I could not get the video element to be displayed at all. I spent half an hour debugging in multiple browsers and still could not get the element to show up. I was on the edge of calling someone for help when I noticed this:

Lesson learned: Always pay attention to the most basic styles (often without any media query restriction) that are applied to parent elements and are hiding on the top of your stylesheet files.