How to use i18n in gatsby without harming performance

This issue is being resolved in #50

How to bring feedback to the developers their components ruined performance and how will we disable the installation of this component into the stores

We should make the product image progressive load with the same height/width as in product summary so that in navigation we display the image right away

While receiving a request, we need to revalidade the json based on the query before returning the data, so when the query changes we don't break the front end and don't need to regenerate the whole jsons database

For the MVP, RC should be a gatsby-plugin that can be developed maintained independently. However, gatsby-theme-vtex should always include it

We could try a strategy where we incrementally build buckets of pages in parallel.

Discussion started here: https://vtex.slack.com/archives/C0164SHMAV9/p1595461929019400

Further reading:

https://medium.com/harrys-engineering/how-we-used-gatsby-js-to-build-a-blazing-fast-e-commerce-site-a9818145c67b

https://www.npmjs.com/package/gatsby-parallel-runner

https://www.gatsbyjs.org/docs/conditional-page-builds/

Today we are creating one bucket per project to be built. Example storecomponents.store has a bucket where is saves the static assets gen per build in a structure git branch alike, e.g: master/public, branch-1/public, branch-2/public, etc...

Is this method ok? Are we gonna use S3, a S3 wrapper or other repo / filesystem method? This should be validated with @vtex/io-infra and @Reliability teams.

Every PR should trigger a build pipeline.
Pipelines could also be triggered by commits.

We should validate if Jenkins attend our constraints.

• 3000+ tenants asking for build with builds executed very fast.

In case jenkins doesn't attend we could have a plan b with kafka consumers or other pipeline frameworks like drone IO, circle CI, tekton pipelines, jenkins X, etc...

Validate if we could have security issues by running unknown (custom builds) code in our build framework.

One thing we should test is how "long pages" (with a long below the fold) content behaves in terms of performance in lighthouse.

The tests are being done in here:
preview
gatsby-vtex
storecomponents.store

Things we would like to discuss

• Should data fetching be co-locate with components ? (0)
• Should we split data fetching from state management ? (1)
• Is it ok to explicitly split sync and async data ? (2)
• Is using graphql ok for data fetching ? (3)
• Should we expose a store sdk (useSku, useOrderForm) instead of our graphql layer ? (4)
• Which libraries would you like to use ? (Apollo, swr, graphql-request, graphql-anywhere, urql ) (5)

Any other comment ?

We should check if it's possible to return only the above the fold page without harming performance (layout shift)

Ok, so this is a big one.

Sooner or later, our app will have to deal with loading state. Currently, there are two main ways of dealing with loading state in your app. The first design pattern is to have a dedicated component that Previews the final state of another component. This design pattern is common in post-suspense era components, where you need to provide a fallback component to React's <Suspense/> component. An example is:

<Suspense fallback={<Preview/>}>
   <ActualComponent/ >
<Suspense/>

The problem with this approach is that the Preview component needs to be in sync with and needs to understand all loading states of the ActualComponent.

The second approach is to craft the loading state into the ActualComponent itself so that when it receives an isLoading prop ActualComponent renders it's loading state. This method is endorsed by react-loading-skeleton library.

After reading the react-loading-skeleton library, I tried to implement their pattern for previewing the product summary's price. The result was a noticeable reduction in TBT score.
This reduction happens mainly for two reasons:

1. When adding loading state into the component, the loading state is rendered by the leafs in the react tree, what makes the browser to run all of the component's code on hydration. If we use the Preview component the react tree is shallower
2. react-loading-skeleton computes and adjusts it's size to it's parent element, what adds more CPU intensive work to the first hydration

The conclusion we can get from these results is that we should try to make the loading state happens as early as possible for avoiding the browser to parse unnecessary JS. However, don't try making a complex loading state. It's ok to break the loading state into smaller, cohesive loading states.

Is it possible to load prices lazily in the search page without harming performance ?

We should definitely check google's RFC on this
https://docs.google.com/document/d/1wY2fKqUIFZbgfZZXQ1k9G-Lu5eT0Q45u6-RbW0vYTyQ/edit#heading=h.a5c3g187gp63

How do they achieve that?

Is it possible to build only some pages and add the result to a current build ?

does it harm performance

https://docs.google.com/document/d/1wY2fKqUIFZbgfZZXQ1k9G-Lu5eT0Q45u6-RbW0vYTyQ/edit#heading=h.a5c3g187gp63

Progress is being done in here: https://github.com/vtex-sites/storecomponents.store/pull/70

Is it possible to build only some pages and add the result to a current build ?

We should only build the files that have changed. Could Jenkins or other CI pipeline framework attend us?

Gatsby generates two types of files: static files with rendered HTML, static files that requests data on the client side.

We want to inline the product data in the dynamic HTML so we can "sync render" on the client.

We should accept different calls asking for different builds. CMS ask for build, change on products ask for build, etc...

I think we could use a technique of useEffect with requestIdleCallback so we only render ReactHelmet when the CPU is idle

We should check if google accepts this kind of behavior