Pro 9889 jsx conversion - #565
Conversation
boutell
left a comment
There was a problem hiding this comment.
Some initial feedback. Recommend you back out the unplanned moves of files (which are showing up as deletions and creations) and address the points around needing to show how access to global and home is actually obtained, then re-request review
| @@ -1,336 +0,0 @@ | |||
| --- | |||
There was a problem hiding this comment.
Not linked from anywhere, but will be cleaned up in another PR. Reverted.
| | `APOS_BASE_URL` | Astro staging frontend URL (set after Part 2) | `https://your-project.vercel.app` | | ||
| | `NODE_ENV` | Sets production mode | `production` | | ||
| | `APOS_RELEASE_ID` | Unique ID per deploy for cache busting | `${{RAILWAY_GIT_COMMIT_SHA}}` | | ||
| | `APOS_RELEASE_ID` | Unique ID per deploy for cache busting | <span v-pre>`${{RAILWAY_GIT_COMMIT_SHA}}`</span> | |
There was a problem hiding this comment.
why the funny span with v-pre thing for this and not other columns?
There was a problem hiding this comment.
Vitepress tries to interpret double curly braces through mustache interpolation. The wrapping prevents that. This sweep of the docs picked up a few that missed being escaped.
| > **`APOS_EXTERNAL_FRONT_KEY`:** Generate a long random string for this value. It authenticates the Astro frontend with ApostropheCMS. Both Railway and Vercel must use the exact same value or requests will be rejected. Treat it like a password. | ||
|
|
||
| > **`APOS_RELEASE_ID`:** Setting this to `${{RAILWAY_GIT_COMMIT_SHA}}` uses Railway's built-in reference variable to automatically generate a unique value from the git commit hash on every deploy. This is preferable to a static random string, which would remain the same across redeployments. | ||
| > **`APOS_RELEASE_ID`:** Setting this to <span v-pre>`${{RAILWAY_GIT_COMMIT_SHA}}`</span> uses Railway's built-in reference variable to automatically generate a unique value from the git commit hash on every deploy. This is preferable to a static random string, which would remain the same across redeployments. |
There was a problem hiding this comment.
same question each time this appears
| For filter links, prefer `aposData.filters` (derived from `req.data.filters`) over the legacy `aposData.piecesFilters` pattern where possible. This provides filter metadata and pre-built URLs that are consistent with how static paths are generated. | ||
|
|
||
| Note that static mode only supports a single active filter at a time. Combined filters will not have pre-rendered paths and will return 404s. See the note in [Backend Configuration](#3-configure-piece-filters-for-static-generation) above. | ||
| Note that static mode only supports a single active filter at a time. Combined filters will not have pre-rendered paths and will return 404s. See the note in [Backend Configuration](#_3-configure-piece-filters-for-static-generation) above. |
There was a problem hiding this comment.
sanity checking that _3 is correct? I mean maybe
There was a problem hiding this comment.
Yup - the anchor link is numbered and #3-XXX is invalid in, get this, CSS. So, VitePress slugifies during anchor link creation to make them valid.
| {# 👇 Referencing `data.home._children` and looping over them. #} | ||
| {% for page in data.home._children %} | ||
| {/* 👇 Referencing `home._children` and looping over them. */} | ||
| {home._children.map((child) => ( |
There was a problem hiding this comment.
Does not show how we got hold of home and global in the first place. A more complete example that does that is called for
There was a problem hiding this comment.
Fixed here and in one other instance on guide/pages.md.
|
( As a matter of fact they are properties of the |
boutell
left a comment
There was a problem hiding this comment.
LGTM 😄 I did a bunch of spot checking; it's rather epic, of course, but feels good to me.
|
Let me know when this lands, I want to bring in WYSIWYG Fields documentation after that. |
Please indicate which branch this PR should merge into:
Check one
Summary
Summarize the changes briefly, including which issue/ticket this resolves. If it closes an existing Github issue, include "Closes #[issue number]"
This PR converts a large majority of the templates to JSX. It also introduces a number of fixes. It should not be published until the two starter kit JSX branches land. Closes PRO-9889.
What are the specific steps to test this change?
For example:
What kind of change does this PR introduce?
(Check at least one)
Make sure the PR fulfills these requirements:
If adding a new feature without an already open issue, it's best to open a feature request issue first and wait for approval before working on it.
Other information: