[ch579]
Some README files in `examples/cms-*` were linking to a documentation markdown file inside the repo (e.g. `/docs/basic-features/pages.md`) instead of the documentation website. We should always link to the documentation website from an example README file because (1) the website has better UX and (2) as we’re creating the examples pages on `next-site` (https://github.com/vercel/next-site/pull/672), we’d like to avoid extra processing of markdown content.
I added the commented code with the `AppContext` type to match the example from the [Custom App](https://nextjs.org/docs/advanced-features/custom-app) page. But since this is the TS page I think we could remove these comments and use a clean example, what do you think? 🤔
So I can't *entirely* explain why, but I believe this fixes#13132. 🙈 I basically ended up looking around at other `_next` URLs (are those asset URLs?) around the project and seeing that they tended to use `delBasePath()` to remove the base path from the current page's path whenever it was used.
When testing locally with the [repo submitted with the issue](https://github.com/robertovg/next-base-path-example), I no longer experience the constant page-reloading in dev mode when adding a query string to the URL.
- Fixes the Next.js `with-graphql-hooks` example so that data is prefetched during SSR:
- The example was using an old version of `graphql-hooks` where SSR was broken
- It had a bug where the `graphql-hooks` client passed in to the `AppTree` as a prop was not being used (instead was creating a new client every time)
This resolves https://github.com/nearform/graphql-hooks/issues/439 for `graphql-hooks`.
Related to [11014](https://github.com/vercel/next.js/issues/11014).
Removed getInitialProps in favor of getStaticProps and getServerSideProps. Refactored one of the components from class to functional. Removed redundant imports. Removed React.FC/FunctionComponent. Added two build files to gitignore.
Let me know if you want something to be changed.
Based on https://github.com/vercel/next.js/pull/13607 - I created a new PR as I can't push changes to the initial PR.
Migrated the Apollo client to use SSG, also removed the link to the live demo because I don't know who the owner is or how to update the deployment.
The implementation is pretty simple and will be added to all the other Apollo examples
* Add Cosmic CMS Example
* with native .env support, this file isn't needed anymore
* FIX use path alias
* Add cosmicjs package
* Fix alias import in pages/api/preview
* Added: react-imgix & lazysizes package
* Load lazysizes in layout
* Used imgix image with lazyloading
* Added avatar imgix optimizations
* EDITED: steps to install content, preview
* EDITED: demo link
* EDITED: Install step
* EDITED: preview link steps
* Edited: demo link
* FIXED: object_slug
* Screenshots
* Fixed object_slug link
* Update README.md
* Fix: formatting issue
* Updated readme and renamed .env to env.local
* Sanity checks
* Handle fallback data when expected
* Added link to the example in other examples
* Updated demo deployment
* Added example to docs
* minor lint fix
* Remove manual download step
* use vercel.json
Co-authored-by: Tony Spiro <tspiro@tonyspiro.com>
Co-authored-by: Luis Alvarez <luis@vercel.com>
This error isn't specific to just fallback SSG pages since any dynamic SSG page that is rewritten to can cause the `/_next/data` request to fail also since it currently derived from the the URL.
This can also fail for `getServerSideProps` since it derives the `/_next/data` URL the same way so might need to be updated to show in that case also
Disambiguate between pages/index.js and pages/index/index.js so that they resolve differently.
It all started with a bug in pagesmanifest that propagated throughout the codebase. After fixing pagesmanifest I was able to remove a few hacks here and there and more logic is shared now. especially the logic that resolves an entrypoint back into a route path. To sum up what happened:
- `getRouteFromEntrypoint` is the inverse operation of `getPageFile` that's under `pages/_document.tsx`
- `denormalizePagePath` is the inverse operation of `normalizePagePath`.
Everything is refactored in terms of these operations, that makes their behavior uniform and easier to update/patch in a central place. Before there were subtle differences between those that made `index/index.js` hard to handle.
Some potential follow up on this PR:
- [`hot-reloader`](https://github.com/vercel/next.js/pull/13699/files#diff-6161346d2c5f4b7abc87059d8768c44bR207) still has one place that does very similar behavior to `getRouteFromEntrypoint`. It can probably be rewritten in terms of `getRouteFromEntrypoint`.
- There are a few places where `denormalizePagePath(normalizePagePath(...))` is happening. This is a sign that `normalizePagePath` is doing some validation that is independent of its rewriting logic. That should probably be factored out in its own function. after that I should probably investigate whether `normalizePagePath` is even still needed at all.
- a lot of code is doing `.replace(/\\/g, '')`. If wanted, that could be replaced with `normalizePathSep`.
- It looks to me like some logic that's spread across the project can be centralized in 4 functions
- `getRouteFromEntrypoint` (part of this PR)
- its inverse `getEntrypointFromRoute` (already exists in `_document.tsx` as `getPageFile`)
- `getRouteFromPageFile`
- its inverse `getPageFileFromRoute` (already exists as `findPageFile ` in `server/lib/find-page-file.ts`)
It could be beneficial to structure the code to keep these fuctionalities close together and name them similarly.
- revise `index.amp` handling in pagesmanifest. I left it alone in this PR to keep it scoped, but it may be broken wrt nested index files as well. It might even make sense to reshape the pagesmanifest altogether to handle html/json/amp/... better
The current [with-polyfills](https://github.com/vercel/next.js/blob/canary/examples/with-polyfills/) example is not the suggested way to add polyfills and is known to cause issues with bundling.
The proper way to load polyfills is to include them as the first line in `pages/_app.js`, which I've updated the docs to say.
Closes [7882](https://github.com/vercel/next.js/issues/7882).
Created as requested by @timneutkens
I'm unsure if that's exactly what you wanted, so let me know what you want me to change and I'll do it asap.
When reading
"In order to expose a variable to the browser you can prefix the variable with NEXT_PUBLIC_. For example:"
I thought that I could maybe use something else than NEXT_PUBLIC_. I guess "have to" or similar would be better here, let me know
Prefixed variables name with NEXT_PUBLIC_.
Solving #13585 issue related to get undefined from process.env.VARNAME inside .env* files.
I'm not secure if SESSION_SECRET_* need the prefix.
Related to [11014](https://github.com/vercel/next.js/issues/11014)
1. Moved the reducer into the store and created new store file
2. The example was using a server that was no longer available, now it uses JSON placeholder instead.
3. Moved from getInitialProps to getStaticProps
4. Refactored all the classes to functional components, using the new redux hooks API.
5. Upgraded all the packages and using custom redux wrapper instead of next-redux-wrapper, which I have removed from the example.
6. Upgraded all the other packages.
Please, let me know if I should change anything.
**First, apologies for a second PR on the same issue but I was working on this already so I thought I'd push it and let you decide which you want to merge.**
The PR is related to [13466](https://github.com/vercel/next.js/issues/13466).
Based on my research, the error happens if the options are empty, null, or undefined. That's why I have decided that the most proper check would be using the! post-fix expression operator may assert that its operand is non-null and non-undefined. ``if (options == null)``
(Optional)
I have also added a warning, which warns the user if the passed "dev" variable is not a boolean.
It's my first PR on the "packages" part of the repo so I'd be glad to receive all kinds of critics. If you want me to change or remove anything, I'm open to suggestions.
---
Fixes#13466
The [docs for customising the PostCSS config](https://nextjs.org/docs/advanced-features/customizing-postcss-config) warn the user they will need to manually install any dependencies that Next.JS will implicitly use if the config is not overridden. `postcss-preset-env` is missing from the install command.
