Improve demo (UI/UX) + better examples

[Vadorequest]

Status

PR in progress at #52

Context

@jajourda @samuelcastro I'd like to know what you think about the current demo (e.g: https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-oylx1iihd.now.sh/fr)

I think we should add more example and restructure those examples (UI/UX)

It's mostly visual, but do you have any idea about how to do it better? Would you like to work on it?

Quick list of stuff we should showcase (IMHO):

• ✅ Use of getStaticProps (SSG)
  • Done in 3 pages
• ✅ Use of getStaticProps with fallback (?)
• ✅ Use of getStaticProps with revalidate (?)
• ✅ Use of getServerSideProps (SSR)
  • Done at /products
• 🏁 Use of getInitialProps (SSR+CSR), should we? I prefer the new getSP/getSSP way, cleaner
• ✅ Use of different locales/lang
  • Done in all pages
• ✅ Use of i18next features
  • Done in the /examples page
• ⚠️ Use of i18nLink (client side navigation with i18n support)
  • Done in all pages, but now shown explicitly in the demo
• ✅ Use of custom 404
• ⚠️ Use of core hooks
  • Done in multiple files/pages, but now shown explicitly in the demo
• ✅ Use of Apollo HOC
  • Done in many pages, both with SSR/SSG (not done with getInitialProps, should we? 🤔)
• ⚠️ Use of graphQL queries
  • Done in many pages, but now shown explicitly in the demo
• ✅ Use of CSR links
  • Done in many pages
• ✅ Use of analytics (Amplitude)
  • Done in all pages, demo at /examples
• ✅ Use of monitoring (Sentry)
  • Done in all pages, demo at /examples
• ✅ Use of API
  • Demo at / with /api/status
• ✅ 500 top-level error (would display native 500 error page I guess)
• ✅ 500 page error (would display page with DefaultErrorLayout)
• ✅ 404 page (no obvious example, but easy to reproduce, unlike 500 errors)

Is there anything important we're missing?

[samuelcastro]

So these are my thoughts:

• I don't think we need to show up getInitialProps, next.js is slowly moving away from it.
• Include support for Incremental Static Generation would be a great bonus, since it's fairly new feature/concept.
• I honestly don't like reactstrap/bootstrap, it'd be great to use styled-system and maybe rebass, they're based off atomic and subatomic design systems.
• Would be great to breakdown all pages into reusable components.
• Targeting the project to serverless would be a good optimization.
• Considering that GraphCMS is so expensive for production, maybe we should consider other options like Strapi with Graphql or something else.

What do you think?

[Vadorequest]

Thanks for the feedback, gonna answer point by point:

- I don't think we need to show up getInitialProps, next.js is slowly moving away from it.

✅ Agreed. Let's avoid those and focus on the new API getStaticProps and getServerSideProps.

- Include fallback and revalidate would be interesting since they're fairly new features.

✅ Agreed. How would you like to showcase those 2 features?

- I honestly don't like reactstrap/bootstrap, it'd be great to use styled-system and maybe rebass, they're based off atomic and subatomic design systems.

🤔 I don't like bootstrap much either, but I'm not sure about changing it at this point. It's still more commonly known and rather easy to use, while SS/Rebass look like they need more boilerplate to get started. They're interesting, and their advanced compatibility with Emotion is great, I'm just not sure if it's better for getting started, kinda worried about added complexity.

- Would be great to breakdown all pages into reusable components.

✅ Agreed. I believe it's already the case for components that are actually being reused, like products.

- Targeting the project to serverless would be a good optimization.

🤔 Isn't it already the case?

- Considering that GraphCMS is so expensive for production, maybe we should consider other options like Strapi with Graphql or something else.

🔴 Not right now, I want to avoid changing everything with this PR/branch. GraphCMS is great for POCs because it's free and managed (no need to self-host), which actually reduces complexity for testing things around. I agree that using something else (like Strapi) is probably what people will do in the end, but it's just a matter of changing the API endpoint (and dealing with BC like i18n content).

For this reason, I intend to keep GraphCMS around, maybe we'll add a Strapi example, as an alternative, at some point. But not now.

Also, I'm strongly considering Airtable as the next API alternative, because it's free and isn't as limited as GCMS, and also it's different (REST-ish API) so it's a good use case, and very very good for POCs (may likely become the default preset/demo).

[samuelcastro]

• Include fallback and revalidate would be interesting since they're fairly new features.

✅ Agreed. How would you like to showcase those 2 features?

I think we should keep this simple, maybe create a sample fallback page that will be static generated on-demand, maybe something like https://static-tweet.now.sh/

• I honestly don't like reactstrap/bootstrap, it'd be great to use styled-system and maybe rebass, they're based off atomic and subatomic design systems.

🤔 I don't like bootstrap much either, but I'm not sure about changing it at this point. It's still more commonly known and rather easy to use, while SS/Rebass look like they need more boilerplate to get started. They're interesting, and their advanced compatibility with Emotion is great, I'm just not sure if it's better for getting started, kinda worried about added complexity.
Ok that make sense, the focus here is more next.js rather than best UI/UX pratices.

• Targeting the project to serverless would be a good optimization.

🤔 Isn't it already the case?

I meant, the target: "serverless" on next.js (https://nextjs.org/docs/api-reference/next.config.js/build-target#serverless-target), but I just realized that deployments to Vercel will automatically enable this target, so we're good.

• Considering that GraphCMS is so expensive for production, maybe we should consider other options like Strapi with Graphql or something else.

🔴 Not right now, I want to avoid changing everything with this PR/branch. GraphCMS is great for POCs because it's free and managed (no need to self-host), which actually reduces complexity for testing things around. I agree that using something else (like Strapi) is probably what people will do in the end, but it's just a matter of changing the API endpoint (and dealing with BC like i18n content).

For this reason, I intend to keep GraphCMS around, maybe we'll add a Strapi example, as an alternative, at some point. But not now.

Also, I'm strongly considering Airtable as the next API alternative, because it's free and isn't as limited as GCMS, and also it's different (REST-ish API) so it's a good use case, and very very good for POCs (may likely become the default preset/demo).

Ok, that make sense, once again, that's not the main goal here.

Also I think it would be great to mesure performance to show up how good this setup is in terms of performance, accessibility, best practices and SEO.

This is the current score the demo has on lighthouse:

[Vadorequest]

I think we should keep this simple, maybe create a sample fallback page that will be static generated on-demand, maybe something like static-tweet.now.sh

Good idea. Re-implementing their Twitter example is possible.

I meant, the target: "serverless" on next.js (nextjs.org/docs/api-reference/next.config.js/build-target#serverless-target), but I just realized that deployments to Vercel will automatically enable this target, so we're good.

I hadn't noticed that. They say we shouldn't opt-in if we use Vercel, so keeping it as it is probably good enough. But I'd like to make it obvious, so I'll add a comment about it for transparency.

Also I think it would be great to mesure performance to show up how good this setup is in terms of performance, accessibility, best practices and SEO.

Great suggestion. I've just gone through https://nextjs.org/blog/next-9-4#integrated-web-vitals-reporting and I believe we could implement it very easily with the built-in Amplitude analytics. Does that sound good?

It'll allow to track performances for each rendering, I'll take a deeper look and add it to to-do things.

[samuelcastro]

Great suggestion. I've just gone through https://nextjs.org/blog/next-9-4#integrated-web-vitals-reporting and I believe we could implement it very easily with the built-in Amplitude analytics. Does that sound good?

Yeah, that sounds great.

I'm excited about this :)

[Vadorequest]

Adding errors to the list:

• 500 top-level error (would display native 500 error page I guess)
• 500 page error (would display page with DefaultErrorLayout)
• 404 page

[samuelcastro]

Should we add the prod rollback if E2E is failing here?

[Vadorequest]

I'll rather open a separate issue

[Vadorequest]

WIP at #52

[Vadorequest]

I'm almost done with the Demo rewrite. Latest demo at https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-g99eujlm6.now.sh

What's coming next is proper examples for SSG/R with their variations (revalidate, fallback)

[Vadorequest]

Example with fallback mode has been implemented, it was a bit harder than I thought so.

Now, a isSSGFallbackInitialBuild variable is available in all pages as prop, and helps to know if the page was was built during the current "request".

[Vadorequest]

Fallback mode available at https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-8zo69v8h2.now.sh/fr/examples/native-features/example-with-ssg-and-fallback/111

[Vadorequest]

Revalidate demo available at https://nrn-v1-hyb-mst-aptd-gcms-lcz-sty-c1-i6tj62ina.now.sh/fr/examples/native-features/example-with-ssg-and-revalidate

PR is ready and has implemented all requirements, I'll merge.

[Vadorequest]

Merged through https://github.com/UnlyEd/next-right-now/pull/42/commits/555b44b13b33415bfb0f3b0a7fb1d00debe28ced