fix: rename next to remix #9961
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
remorses
reviewed
Sep 8, 2024
| @@ -13,7 +13,7 @@ | |||
| "isolatedModules": true, | |||
| "esModuleInterop": true, | |||
| "jsx": "react-jsx", | |||
| "module": "ESNext", | |||
| "module": "ESRemix", | |||
|
LGTM 👍🏻 |
amatzen
reviewed
Sep 8, 2024
| @@ -79,7 +79,7 @@ export function ProjectList({ projects }) { | |||
| } | |||
| ``` | |||
|
|
|||
| Or add a spinner next to it by inspecting params: | |||
| Or add a spinner remix to it by inspecting params: | |||
Thanaen
reviewed
Sep 8, 2024
| @@ -263,7 +263,7 @@ We found that the `future.unstable_fogOfWar` flag name could be a bit confusing | |||
|
|
|||
| The original Single Fetch approach was based on an assumption that an eventual `middleware` implementation would require something like the `ResponseStub` API so users could mutate `status`/`headers` in `middleware` before/after handlers as well as during handlers. As part of Single Fetch, we wanted to align how response headers would be merged between document and data requests. Thinking `response` was the future API, we aligned document requests to use the `response` stub that data requests were using, and we stopped using the `headers()` function. | |||
|
|
|||
| However, the realization/alignment between Michael and Ryan on the recent [roadmap planning](https://www.youtube.com/watch?v=f5z_axCofW0) made us realize that the original assumption was incorrect. `middleware` won't need a `response` stub - as users can just mutate the `Response` they get from `await next()` directly. | |||
| However, the realization/alignment between Michael and Ryan on the recent [roadmap planning](https://www.youtube.com/watch?v=f5z_axCofW0) made us realize that the original assumption was incorrect. `middleware` won't need a `response` stub - as users can just mutate the `Response` they get from `await remix()` directly. | |||
There was a problem hiding this comment.
I'm not sure we should rename "next" to "remix" here 😄
Hammster
reviewed
Sep 9, 2024
| @@ -275,7 +275,7 @@ With this change: | |||
| - ✅ `return { data: "whatever" };` | |||
| - If you _were_ returning a custom `status` or `headers` via `json`/`defer`: | |||
| - We've added a new API-compatible [`unstable_data`](https://remix.run/docs/utils/data) utility that will let you send back `status`/`headers` alongside your raw data without having to encode it into a `Response` | |||
| - We will be removing both `json` and `defer` in the next major version, but both _should_ still work in Single Fetch in v2 to allow for incremental adoption of the new behavior | |||
| - We will be removing both `json` and `defer` in the remix major version, but both _should_ still work in Single Fetch in v2 to allow for incremental adoption of the new behavior | |||
There was a problem hiding this comment.
That looks like a search and replace mistake
There was a problem hiding this comment.
no this looks right to me, the remix major version
| @@ -93,9 +93,9 @@ You may need to make changes to a pre-release prior to publishing a final stable | |||
| - Once the release is published: | |||
| - Pull the latest `release-*` branch containing the PR you just merged | |||
| - Merge the `release-*` branch into `main` **using a non-fast-forward merge** and push it up to GitHub | |||
| - `git checkout main; git merge --no-ff release-next` | |||
There was a problem hiding this comment.
Next in here is also not referring to the framework name
There was a problem hiding this comment.
we're trying to release-remix not release next js
| @@ -30,7 +30,7 @@ In [Remixing React Router][remixing router], Ryan gives an overview of the work | |||
|
|
|||
| ### Move the bulk of logic to a framework-agnostic router | |||
|
|
|||
| Thankfully this decision was sort of already made by Ryan. Maybe a surprise to some, maybe not, the current transition manager doesn't import or reference `react` or `react-router` a single time. This is by design because the logic being handled has nothing to do with how to render the UI layer. It's all about "what route am I on?", "what route am I going to?", "how do I load data for the next route?", "how do I interrupt ongoing navigations?" etc. None of these decisions actually _care_ about how the route and its data will eventually be rendered. Instead, the router simply needs to know whether given routes _have_ components and/or error boundaries - but it doesn't need to know about them or how to render them. | |||
|
LGTM! |
|
lol |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
when remix was forked from next it looks like you forgot to rename some things, this PR finishes renaming them to Remix