DEV Community: Alexandre Fauchard

Storybook x React x Typescript | How to manage complex props with simple control

Alexandre Fauchard — Sun, 01 May 2022 17:30:58 +0000

The problem

When you're implementing a Storybook you can change your components props with Storybook's controls. But sometimes, when you have a complex props, controls are not adapted and you may need multiple control for one props and/or have to mock some data.

The problem come with Typescript, your argTypes is waiting for a type equals to the component props type. But I have a good news ! I'm going to give you a trick to properly bypass this problem.

The trick

Let's take a "simple" complex prop as an example :
I have a component Heading with props which have this type :

type HeadingPropType = {
  text : {
    text : string
    html : ReactNode
    raw : string
  }
  image : {
    url : string
    alt : string
  }
}

As you can see we have two props :

text : a string displayed in multiples format
image : an image url with an alt attribute which will not be very useful in a Storybook

With this type of props, Storybook will display controls which ask the user to fill an object but I guess we all agree that a string and an input file are more suitable.

We can display them simply with ArgTypes but making them work is a bit more complicated.
What you need is a HOC (Higher Order Component) which will return your component but with simplified props.

Something like this :

const componentSimplifier = <T1, T2>(
  ComplexComp: React.ComponentType<T2>,
  propsConverter: (props: T1) => T2
) => (props: T1) => <ComplexComp {...propsConverter(props)} />

These line define the function componentSimplifier which takes two Generics Types (T1, the simple one and T2, the component props type) and two arguments :

ComplexComp : Simply the component you want to add in your story
propsConverter : A function that will convert simple props into complex ones

For our example we have :

T1 = {
  text : string
  image : string
}
T2 = HeadingPropType
ComplexComp = Heading //The component we want to display
propsConverter = ({text, image}: T1) => ({
  text : {
    text : text,
    html : <h1>${text}</h1>,
    raw : text,
  },
  image : {
    url : image,
    alt : "default alt string"
  }
})

The final call to this function will be :

const SimpleHeadingPropsType = {
  text : string
  image : string
}

const propsConverter = ({text, image}: T1) => ({
  text : {
    text : text,
    html : <h1>${text}</h1>,
    raw : text,
  },
  image : {
    url : image,
    alt : "default alt string"
  }
})

const SimplifiedHeading = componentSimplifier<
  SimpleHeadingPropsType,
  HeadingPropType
>(
  Heading,
  propsConverter
)

That's it ! Now you can use SimplifiedHeading in your story with adapted controls !

Fix Gatsby 4 matchPath issue

Alexandre Fauchard — Mon, 25 Apr 2022 07:54:07 +0000

Introduction

If your Gatsby website has a lot of pre-generated pages, you may have noticed that your app.js file grows fast. That's because from the moment you add a matchPath to one of your pages, Gatsby will write every pre-generated "child page route" in the app.js file.

💡 By "child page route" I mean all pages with same level or deeper level path.

It can concern some parts of your website if you are using a fallback route or, in the worst case, every page of your site if you choose to implement a custom 404 page.
This results in a more and more longer page loading on every page and a catastrophic SEO side effect.

Let's take an example

We have a news website where the journalist post some hot posts. Our website is pre-generated every 10 minutes and build every news with the route /news/{id}. But if a journalist post a news, users have to be able to see it before the next build.
At every moment, we can split our pages in two parts : the generated news and the non-generated news.
Problem : both types have the same route /news/{id}. How to access news created after the last build ?

This issue can shortly be solved with a matchPath. All we have to do is to add this code anywhere in our createPages function

/* ... */
createPage({
  component: newsFallbackTemplate,
  context: newsContext,
  matchPath: "/news/*",
  /* ... */
})
/* ... */

The created page will be shown each time the user access a non-pre-generated page with path starting with /news/. We just have to handle API calls in the newsFallbackTemplate component to display our news.
In fact, it's work really well. The only problem is the way Gatsby handle it. To better understand why, let see, schematically, what append when a user visit your website at the path /news/ex_6.

The loadPage process

When a page is loading, there are two functions called.

First, the window.loadPage function is called. It's looking for the component matching with the path it's loading.

💡 On an SSG page, it display the pre-generated files and "confirm" the used component.

The process give priority to the more detailed path following this algorithm. To achieve this, the loadPage use the app.js file to get all paths and matchPaths. Once the component is loaded, the page is displayed.

💡 If you don't have any matchPaths, Gatsby will only use the pre-generated data but if you have at least one matchPath, Gatsby have to verify that he display the right component. That's why the app.js will contain every path and matchPath and will grow proportionally with your page number.

Then, the window.loadPageSync will execute to double-check this result.

In our case, when the browser loads the path /news/ex_6, as we have at least one matchPath page, the loadPage function will look into our app.js file. This file will contain an array which look like this

[
  {"path" : "/news/ex_1", "matchPath" : "news/ex_1"},
  {"path" : "/news/ex_2", "matchPath" : "news/ex_2"},
  /* ... */
  {"path" : "/news/ex_5", "matchPath" : "news/ex_5"},
  {"path" : "/xxx", "matchPath" : "news/*"},
]

Using the algorithm link before, it will return the component corresponding to the path /xxx as the closer matchPath is news/*. The component should be newsFallbackTemplate and will handle all API calls to display our news as a pre-generated one. Everything work fine but in our case we have only 5 pre-generated news so the app.js array only have 6 entries. But if we have 100K news pre-generated, the array will be huge as well as our app.js file.

How to fix it

To fix it, we'll need to replace the way matchPath are handle.

First, we will replace all our matchPath by a static path like /__fallback/__xxx. The createPage call we write at the beginning to handle non-pre-generated news will now look like this

/* ... */
createPage({
  component: newsFallbackTemplate,
  context: newsContext,
  path: "/__fallback/__news_fallback",
  /* ... */
})
/* ... */

We now have a static loading page for every old matchPath page.

Then, we will add to our newsFallbackTemplate component the following code

return (
  /* ... */
  <Helmet>
    <script>
      {`
        window.pagePath = undefined
        window.news__routeParams = {
          path : "/__fallback/__news_fallback",
          matchPage : "/news/*"
        };
      `}
    </script>
  </Helmet>
  /* ... */
)

This will add to the page a script which will add to the global window variable a property news__routeParams with the static path .

💡 Replace news__ prefix by your app name to avoid interferences

Finally, in the gatsby-browser file, we add an exported function onClientEntry to handle these data. This function will rewrite the loadPage and loadPageSync functions to add the logic to handle our custom matchPath, only if news__routeParams is defined. The onClientEntry shape will look like this

const { ___loader: loader, news__routeParams } = window

if (!loader) {
  return
}

//Original loadPage functions, to call them later
const originalLoadPage = loader.loadPage
const originalLoadPageSync = loader.loadPageSync

if (news__routeParams) {
  loader.loadPage = async rawPath => {/* ... */}

  loader.loadPageSync = rawPath => {/* ... */}
}

`loadPage`

The loadPage function will be the bigger,

loader.loadPage = async rawPath => {
  const path = news__routeParams.path
  const matchPath = news__routeParams.matchPath
  const lastActualPath = window.news__lastActualPath

  const isFallbackPage = !!path
  //As this function is executed before the url change, we still detect a
  //fallback page if we are leaving one so we need to know if we are leaving or not
  const isLeavingFallbackPage =  !!lastActualPath && lastActualPath !== rawPath

  let pageResources

  //If we detect a fallback Page and we're not leaving we override the pagePath 
  //with the loader page path and we add a matchPath corresponding to the 
  //wanted page url with the last part replaced by *
  if (isFallbackPage && !isLeavingFallbackPage) {
    pageResources = await originalLoadPage(path)
    const rawParts = rawPath.split("/")
    rawParts.splice(rawPath.slice(-1) === "/" ? -2 : -1)
    pageResources.page.matchPath = matchPath ?? [...rawParts, "*"].join("/")
  } else {
    //If we detect a non-fallback page or leaving one
    pageResources = await originalLoadPage(rawPath)
  }

  //We save some data for later
  window.news__lastActualPath = rawPath
  window.news__savedPageRessources = pageResources
  return pageResources
}

As you can see, we check if we're loading a fallback page (with matchPath) or not. In the case of a fallback page, we first load the pageResources (component, page-data.json, ...) with the original function (originalLoadPage) called with news__routeParams.path instead of the actual path (rawPath). Then, we set the pageRessource's matchPath to the window.news__routeParams.matchPath
Thanks to this, if the user load news/ex_6 (which is not pre-generated) the loadPage function with load the pageResources of the link /__fallback/__news_fallback and display it.

`loadPageSync`

At the end of the loadPage function, we saved the loaded pageResources into window.news__savedPageRessources. Thanks to this, we can simply return this variable instead of copy-paste the same logic. Obviously, if there is no saved page resources, we return the original function result

loader.loadPageSync = rawPath => {
  return window.news__savedPageRessources ?? originalLoadPageSync(rawPath)
}

You maybe notice, but to make this work, we need to have set the window.news__routeParams variable. But how can we have this variable which is on the fallback template, if we're trying to load this template ? We add a redirect !

⚠️ That's the limit of this solution : it's only work with an hosted instance, not in development. As it's an SEO issue, you can add matchPath in dev mode.

All you have to do is to add this just after the createPage seen before

createRedirect({
  matchPath:`news/*`,
  toPath: `/__fallback/__news_fallback`,
  redirectInBrowser: false,
  statusCode: 200,
})

That's it ! Now our server will transparently redirect (redirectInBrowser: false) to the fallback page which will display the news dynamically. Once the JavaScript is loaded, the loadPage will be executed and, thanks to our modification, will load the same component as well as loadPageSync.

Results

Here is the Lighthouse Treemap results before and after our modifications on a +40K pages Gatsby 4 project.

Before

After

As you can see, the app.js bundle is drastically smaller !

Maybe Gatsby will solve the problem by himself 🤞🏻

Decompose React children to improve DX

Alexandre Fauchard — Sun, 13 Mar 2022 20:39:58 +0000

Today I needed to make a tab system.
Perfect for display multiple types of data in a small space, a tab system has two parts :

The header always display all the tabs labels
The content part display the data associated to the selected tab

The complexity of this kind of system is that we have a fixed part and a dynamic part, let's see two implementations.

V1 – Simple to code, hard to use

A first idea is to do a simple component with a tabs prop corresponding to an array of objects with a label and a content which can be called like this :

<TabView
    tabs={[
        {
            label : "First tab", 
            content : <p>My first tab content</p>
        },
        {
            label : "Second tab",
            content : <p>My second tab content</p>
        },
        {
            label : "Third tab",
            content : <p>My third tab content</p>
        }
    ]}
/>

I could put content into variable, but it's for the example
The corresponding <TabView> component should look like this :

const TabView = ({tabs}) => {
    const [selectedTabIndex, setSelectedTabIndex] = useState(0)

    return (
        <div>
            <div className="header">
                {tabs.map(tab => (
                    <p>{tab.label}</p>
                ))}
            </div>
            <div className="content">
                {tabs[selectedTabIndex].content}
            </div>
        </div>
    )
}

First problem, I need a conditional tab and with this configuration it's complicated 😕
We have to put the tabs into a variable and add an optional tab if necessary... Something like that :

const displayThirdTab = ...

const tabs = [
    {label : "First tab", content : <p>My first tab content</p>},
    {label : "Second tab", content : <p>My second tab content</p>}
]

if(displayThirdTab){
    tabs.push({label : "Third tab", content : <p>My third tab content</p>})
}

return (
    <TabView
        tabs={tabs}
    />
)

It's starting to get complicated to use, and we can do better. If we change my <TabView> component, we can make a more dev-friendly component which is used like that :

<TabView>
    <Tab label="First tab">
        <p>My first tab content</p>
    </Tab>
    <Tab label="Second tab">
        <p>My second tab content</p>
    </Tab>
    {
        displayThirdTab && (
            <Tab label="Third tab">
                <p>My third tab content</p>
            </Tab>
        )
    }
</TabView>

V2 – Not so difficult to code, much easier to use

The difficulty with the above component lies in the fixed part. We need to display only a part of the children.

To do this, we start by creating a "ghost-component" called <Tab> which will render nothing

const Tab = ({tabs}) => {
    //Rendered in TabView component
    return null
}

With typescript, we can specify the props we need to use them in <TabView>

Then, we will write the base of the <TabView> component.

const TabView = ({children}) => {
    const [selectedTabIndex, setSelectedTabIndex] = useState(0)

    const tabsInfo = []
    const tabsContent = []

    //TODO : Parse children

    return (
        <div>
            <div className="header">
                {tabsInfo.map(({label}) => (
                    <p>{label}</p>
                ))}
            </div>
            <div className="content">
                {tabsContent[selectedTabIndex]}
            </div>
        </div>
    )
}

You can see two arrays :

tabsInfo will contain all the tabs headers data (just a label in our case)
tabsContent will contain all the <Tab> components children props

We now need to parse the children prop to fill our arrays.
To do this, we add a function called parseTab

const parseTab = (node) => {
    //We extract children from the <Tab> props
    tabsContents.push(node.props.children)
    //We extract label from <Tab> props 
    tabsInfo.push({ label: node.props.label })
}

We just have to call it for each node in children with the React.Children.map

React.Children.map(children, parseTab)

Here we are, our final <TabView> component

const TabView = ({children}) => {
    const [selectedTabIndex, setSelectedTabIndex] = useState(0)

    const tabsInfo = []
    const tabsContent = []

    const parseTab = (node) => {
        //We extract children from the <Tab> props
        tabsContents.push(node.props.children)
        //We extract label from <Tab> props 
        tabsInfo.push({ label: node.props.label })
    }

    React.Children.map(children, parseTab)

    return (
        <div>
            <div className="header">
                {tabsInfo.map(({label}) => (
                    <p>{label}</p>
                ))}
            </div>
            <div className="content">
                {tabsContent[selectedTabIndex]}
            </div>
        </div>
    )
}

"Voir plus", ou comment faire un ellipsis personnalisé

Alexandre Fauchard — Sun, 30 Jan 2022 11:22:34 +0000

En HTML/CSS, lorsque votre texte est trop grand pour la place attribuée, vous pouvez ajouter la valeur text-overflow : ellipsis pour afficher … à la fin.

Le problème est que cela fonctionne uniquement sur les textes sur une seule et unique ligne et qu’il n’y a pas moyen de voir le texte en entier.

Aujourd’hui, nous allons donc voir 2 méthodes pour afficher du texte sur une ou plusieurs lignes sans qu’il ne dépasse !

La méthode CSS only

Cette première méthode est probablement la méthode la plus “propre”, elle se réalise uniquement en CSS, mais nous verrons qu’elle n’a pas forcément le meilleur rendu.

Cette méthode consiste à afficher en bas de la zone de texte un élément (ici un pseudo-élément ::before) afin de cacher la fin du texte. De plus, pour éviter que le texte soit coupé en plein milieu d’un mot, nous ajoutons un dégradé sur le coté de l’élément.

Avantages

“Responsive”
CSS only

Inconvénients

Toujours présent meme quand ce n’est pas nécessaire
Dans le cas du ::before, l'élément qui reçoit le onclick est la balise <p>et donc pas uniquement le "Voir plus"

La méthode JS + regex

Le principe de cette méthode est simple : une boucle javascript va parcourir le contenu de la balise de texte (fonctionne aussi bien avec un

qu’avec des headings) et retirer les mots de manière itérative jusqu’à ce que le contenu rentre dans la zone définie.

Ici, nous allons pouvoir définir une balise (inline) qui sera ajouté à la fin du texte, elle sera ainsi parfaitement intégrée au texte d’origine. De plus, la vérification reposant sur le viewport, l’élément « voir plus » n’est ajouté que s’il est nécessaire !

Avantages

Intégration parfaite
Répond à tous nos besoin : cache le texte en trop et permet d’afficher quand même ce texte grâce à un bouton fonctionnel

Inconvénients

Processus un peu lourd
- Processus d’implémentation un peu lourd et nécessitant l’utilisation du javascript
Besoin de recalculer si changement de viewport