diff --git a/docs/_includes/installation-guide-full.md b/docs/_includes/installation-guide-full.md index a1cac1e..751adca 100644 --- a/docs/_includes/installation-guide-full.md +++ b/docs/_includes/installation-guide-full.md @@ -1,11 +1,12 @@ - This assumes you've cloned the NRN repository locally (cloning it once is enough, no need to clone it multiple times, but it may be simpler to use one clone per variant if you're trying out multiple variants locally :wink:) - This assumes you're already authenticated to Zeit (you should, if you've followed the [quick start](./quick-start), or if you're familiar with Zeit already) -1. `cp .env.build.example .env.build` - Duplicates the `.env.build.example` as `.env.build` _(`.env.build` is only used when working locally)_ +1. `cp .env.build.example .env.build` - Duplicates the `.env.build.example` as `.env.build` + - **Tip**: `.env.build` is only used when working locally 1. Create an account for all required 3rd party vendors above, and fill-in missing environment variables in your `.env.build` file -1. `nvm use` - Selects the right node.js version based on the `.nvmrc` file +1. _(Optional)_ `nvm use` - Selects the right node.js version based on the `.nvmrc` file + - **Tip**: Ignore this if you're not using [NVM](https://github.com/nvm-sh/nvm), but you should! 1. `yarn` - Installs all deps from `package.json` 1. `yarn start` - Starts the app on [http://localhost:8888/](http://localhost:8888/) -1. That's it! The project now works on your local computer, and should be identical to the online demo -{% include installation-guide-tips.md %} +That's it! The project now works on your local computer! diff --git a/docs/_includes/installation-guide-quick-start.md b/docs/_includes/installation-guide-quick-start.md index a7fa477..fe0d929 100644 --- a/docs/_includes/installation-guide-quick-start.md +++ b/docs/_includes/installation-guide-quick-start.md @@ -1,8 +1,13 @@ 1. `git clone https://github.com/UnlyEd/next-right-now.git nrn-quick-start` - Clones the boilerplate 1. `cd nrn-quick-start && git checkout v1-ssr` - Selects the variant -1. `cp .env.build.example .env.build` - Duplicates the `.env.build.example` as `.env.build` _(`.env.build` is only used when working locally)_ -1. `nvm use` - Selects the right node.js version based on the `.nvmrc` file -1. `yarn add -D now@16.7.3`, now@17+ requires to be authenticated to Zeit in order to launch the project **locally**, so you must use now@16 instead, to avoid additional setup +1. `cp .env.build.example .env.build` - Duplicates the `.env.build.example` as `.env.build` + - **Tip**: `.env.build` is only used when working locally +1. _(Optional)_ `nvm use` - Selects the right node.js version based on the `.nvmrc` file + - **Tip**: Ignore this if you're not using [NVM](https://github.com/nvm-sh/nvm), but you should! 1. `yarn` - Installs all deps from `package.json` +1. _(Optional)_ `yarn add -D now@16.7.3` - Installs an older `now` CLI that doesn't require you to have a Zeit account when working locally + - **Tip**: **You don't need to do that if you already have Zeit/Now configured on your computer** _(which may be the case if you're already familiar with Zeit)_ + - **Tip**: `now@17+` requires to be authenticated to Zeit in order to launch the project **locally**, so we recommend to use `now@16` instead in order to avoid unnecessary setup 1. `yarn start` - Starts the app on [http://localhost:8888/](http://localhost:8888/) -1. That's it! The project now works on your local computer, and should be identical to the online demo + +That's it! The project now works on your local computer! diff --git a/docs/_includes/installation-guide-tips.md b/docs/_includes/installation-guide-tips.md index d01e48f..6002f44 100644 --- a/docs/_includes/installation-guide-tips.md +++ b/docs/_includes/installation-guide-tips.md @@ -1,4 +1 @@ -- **Tip**: You can start the project in **debug mode** (built-in for WebStorm only) [by running the WebStorm "Debug" configuration in debug mode](https://youtu.be/3vbkiRAT4e8) - -- **Tip**: Configure your IDE not to index `.next` and `.now` folders as they will eat a lot of your RAM because their files are changed very frequently! - - On WebStorm, right click on the folders and select `Mark directory as > Excluded`. +- **Tip**: Using WebStorm? Check out our ["How to setup" Guide](../guides/ide/setup-webstorm) diff --git a/docs/_includes/page-toc.md b/docs/_includes/page-toc.md new file mode 100644 index 0000000..57f2d2f --- /dev/null +++ b/docs/_includes/page-toc.md @@ -0,0 +1,7 @@ +--- + +## Table of contents +{: .no_toc .text-delta } + +- TOC +{:toc} diff --git a/docs/concepts/i18n.md b/docs/concepts/i18n.md index 56b1bac..104ac8b 100644 --- a/docs/concepts/i18n.md +++ b/docs/concepts/i18n.md @@ -26,30 +26,36 @@ We will only mention i18n with NRN, not l10n. Both are very similar and can be grouped together as i18n, because l10n relies on i18n capabilities. The content displayed on NRN is translated using different ways, depending on where the translations are stored: -- Content i18n - Dynamic content, data related (i.e: Blog title in FR + EN). It will depend on your data and how you fetch those data (API, SSG, etc.) -- Platform i18n - Static content, platform related (i.e: Site links, any content that is static and not related to dynamic data). +- Dynamic i18n - Content-related (i.e: Post title in FR + EN). It will depend on your data and how you fetch those data (API, SSG, etc.) +- Static i18n - Everything that isn't related to dynamic content (i.e: Site links, any content that is static and not related to dynamic data). It will depend on how you fetch those data (vendor (API), i18n static files, etc.) -It is possible, although very rare, to use the same system/vendor for both content and platform i18n. +It is possible, although very rare, to use the same system/vendor for both "dynamic" and "static" i18n. -For instance, one could imagine to store all its static content (platform i18n) within it's content i18n data. This design would have a few pros/cons: +For instance, one could imagine to store all its static content within it's dynamic i18n content. This design would have a few pros/cons: - Content is available online (CMS/back office) and may be updated by non-IT teams - Content needs to be fetched for each request (SSR), but that could be mitigated by using SSG -## A few words on "platform i18n" +## A few words on "static i18n" -I18n with Next.js isn't an easy topic, and our current implementation with platform content (Locize vendor) isn't optimal. +I18n with Next.js isn't an easy topic, and our current implementation with static content (Locize vendor) isn't optimal. -We believe the best way to deal with platform i18n (static content) is to use SSG. -Basically, the process is to fetch your i18n content at build time and generate your pages once and for all. +In short, we believe the best way to deal with static i18n is to use SSG. We currently use SSR, which is definitely sub-optimal and impacts performances and costs. + +### How to get it right + +Basically, the process could be to fetch your i18n content at build time and generate your pages once and for all. This avoids over-fetching your i18n provider for each end-user request, and also remove this vendor from the potential list of threats of your app. (even if your vendor API goes down, it won't affect your end-users because you only use its API at build time) -But it can be complicated to achieve depending on your limitations, and will be impacted by how many pages you have to build, for instance. +Such design also has various benefits and limitations. For example, you can't change static content without rebuilding your app, +but it also increases the speed of your pages because you don't have to fetch static content anymore. + +It can be complicated to achieve depending on your needs and limitations, and will be impacted by how many pages you have to build, for instance. -## A few words on "content i18n" +## A few words on "dynamic i18n" -**Content i18n** is a bit more easier in our opinion. +**Dynamic i18n** is a bit more easier in our opinion. If you need those data dynamically, then you'll have to use your vendor API to fetch the i18n content, the same way you're using its API to fetch non-i18n data. diff --git a/docs/concepts/variants.md b/docs/concepts/variants.md index 4590e7c..cf8ae74 100644 --- a/docs/concepts/variants.md +++ b/docs/concepts/variants.md @@ -8,18 +8,14 @@ nav_order: 1 # Variants {: .no_toc } -## Table of contents -{: .no_toc .text-delta } - -- TOC -{:toc} +{% include page-toc.md %} --- ## What is a variant? -A variant is a variation of the boilerplate. Each variant provides different **built-in** features. - +- A variant is a "variation" of the boilerplate. It's the same as a "Preset" of features that are "ready-to-use", because they're built-in within that variant. +- Each variant provides different **built-in** features. - Each variant lives in the same NRN Github repository, but in a distinct **branch**. - Each variant has its own dedicated demo and "how to install" documentation. @@ -35,8 +31,8 @@ The boilerplate was built with re-usability in mind, but also tries to solve non - Analytics - Monitoring - API usage (consumption) -- Content i18n -- Platform i18n +- [Dynamic i18n](../reference/terminology#nrn-terms) (content) +- [Static i18n](../reference/terminology#nrn-terms) (website) >Those are non-trivial features, and they can't always be build using open source software. > @@ -45,7 +41,7 @@ The boilerplate was built with re-usability in mind, but also tries to solve non Variants are meant to cover as much possibilities as possible. For instance, you may want to use: - SSG or SSR - Multi-tenants or Multiple Single-Tenants or Single Tenant -- Platform i18n with Locize vendor, or implemented using static files (no vendor), or maybe you don't need this feature at all +- Static i18n with Locize vendor, or implemented using static files (no vendor), or maybe you don't need this feature at all - Sentry to monitor your app (client + server sides), but maybe you already use another different vendor and would like to stick with it - Analytics, but because you may use SSG only, and your needs are small then Google Analytics may be a better fit for you and avoid additional complexity - Etc. @@ -66,9 +62,9 @@ It's a waste of time if everybody has to do that on their own, and it strongly l Here is a short list of all variants that we consider to support in the future: - ST (as an alternative to current MST) - SSG (as an alternative to current SSR) -- Platform i18n without Locize provider (as an alternative to current Locize provider, which isn't free) -- No platform i18n and no content i18n support either - (completely remove platform/content i18n support as an alternative for those who don't need related i18n complexity and prefer to keep things simpler) +- Static i18n without Locize provider (as an alternative to current Locize provider, which isn't free) +- No static i18n and no dynamic i18n support + (completely remove any i18n support as an alternative for those who don't need related i18n complexity and prefer to keep things simpler) --- @@ -86,6 +82,26 @@ We do not plan on providing variants for: > > We are therefore open to add more/new tooling, but we must discuss it together first! :wink: +## How do I know which variant is best for me? + +A variant is nothing more than a preset of features that are built-in within. + +So, to decide which one you need, you must compare what features are available versus what features you actually need. +Also, some variants include non-free vendors, or vendors that only provide a limited plan. Depending on those things, you may chose one variant over another. + +Here is a summary of all features that are provided through variants: +- **Manage multiple B2B single-tenants**: Do you need to deploy different sites (one per customer) through the same code base (monorepo design)? If so, we've got you covered. +- **I18n**: Do you need to display your app in multiple languages? + If so, you should start with a variant that allows both ["dynamic i18n" and "static i18n"](../reference/terminology#nrn-terms). + - Also, depending on your needs, you may want to rely on a professional vendor to store, provide and help with i18n. + - For instance, our team love Locize for its [in-context editor](https://docs.locize.com/more/incontext-editor), because it really helps translators understand the context of a sentence, and our marketing/product team can make small changes without having to bother developers. +- **Connect with external APIs**: Do you need to use external APIs? It's very much likely for any app nowadays. + If so, you should start with a variant that provides built-in support. Make sure to select one that fits your needs, we only provide built-in support for GraphQL at the moment. +- **Monitoring**: Do you need to monitor what happens on your server and be warned about bugs and crashes? We bet you do. +- **Analytics**: Do you need to track usage of your features and know how many users visited your site this month? We bet you do. + +- **Tip**: Check out our [**Vendors overview**](../reference/vendors) + ---