🗺️ Remix SPA Target #7638

ryanflorence · 2023-10-11T17:13:43Z

ryanflorence
Oct 11, 2023
Maintainer

Remix SPA

While a React Router SPA and Remix feel very similar, there's still a decent gap between them from a developer ergonomics perspective. This proposal closes that gap allowing Remix to function as a Single Page App.

Additionally, React Router apps don't have a fluid migration path to Remix today. Every loader and action needs to suddenly start working on the server, file system routes need to be figured out from whatever the app was doing before, etc. Along with the #7632 proposal, and the #7634 proposal, this proposal creates a fluid migration path from React Router to Remix. Developers can add a JavaScript backend to their Remix app without changing application code outside of the client entry point.

Proposal

In the vite config, a flag changes the mode to "spa" from the default "ssr".

import { defineConfig } from "vite";
import { unstable_remix } from "@remix-run/vite";

export default defineConfig({
  plugins: [
    unstable_remix({
      // Change the target to "spa"
      target: "spa", // "ssr" | "spa"
    }),
  ],
});

The remix plugin will now only generate client bundles, and normal vite behavior will create the index.html entry point to the app.
It will use the same file conventions for entry.client.tsx, root.tsx, and file system routes.

The route module API remains the same, but the loader and action exports will be ignored, and only the clientLoader and clientAction exports will be used.

export async function clientLoader({ request, params }) {
  let data = await fetch("/api/data");
  return { data };
}

export function clientAction({ request, params }) {
  await saveStuff(request);
  return { ok: true };
}

Imports still come from @remix-run/react not react-router-dom
```
import { NavLink } from "@remix-run/react";
```

Entry points

The HTML entry point for vite is defined at app/entry.html with a script pointing to entry.client.tsx:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Remix SPA</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/entry.client.tsx"></script>
  </body>
</html>

The app entry.client.tsx will need to look a little different than ssr Remix by rendering into a root element instead of hydrating a full document:

import * as React from "react";
import * as ReactDOM from "react-dom/client";
import { RemixBrowser } from "@remix-run/react";

ReactDOM.createRoot(document.getElementById("root")).render(
  <RemixBrowser />
);

Migrating from SPA to SSR targets

To switch to a full stack Remix app with the Remix app server, you simply change the target, but everything else remains the same:

export default defineConfig({
  plugins: [
    unstable_remix({
-      target: "spa",
+      target: "ssr",
    }),
  ],
});

To switch to a custom server, apps will also need to add a server entry file and adapter to the vite config. That setup is discussed in #7632 proposal.

ngbrown · 2023-10-12T04:28:35Z

ngbrown
Oct 12, 2023

Instead of ignoring the loader and action exports when in SPA mode, should errors be thrown? Or at least an eslint warning triggered?

3 replies

ryanflorence Oct 12, 2023
Maintainer Author

yeah, ignored at runtime, but perhaps at build time we can warn if there's a loader/action with a spa target.

rossipedia Oct 15, 2023

I would assume that this would slot in nicely with the clientLoader/clientAction proposal? ie: those would just roughly translate to RR loader/action?

rossipedia Oct 15, 2023

Just caught the callout at the end of the client data proposal, question answered 👍

estevaolucas · 2023-10-12T14:57:00Z

estevaolucas
Oct 12, 2023

That's great! SPA target will probably unlock us to use Remix for micro-frontends powered by Single-Spa + Vite.

1 reply

tomerzcod7 May 24, 2024

@estevaolucas Have you managed to make this work? :)

JimmayVV · 2023-10-17T17:27:55Z

JimmayVV
Oct 17, 2023

you have no idea how relevant this to our current needs. Very hopeful this happens.

0 replies

v-anton · 2023-10-19T14:58:42Z

v-anton
Oct 19, 2023

This is exactly what I wanted to have for our Vite+RR app! Looking forward

0 replies

sergiodxa · 2023-10-19T18:54:37Z

sergiodxa
Oct 19, 2023
Maintainer

This could open the door to a SSG mode in the future that just do SSR and fetch a set of URLs to generate static HTML inside the public folder. It could work in hybrid mode by removing the static routes from the manifest.

5 replies

ryanflorence Oct 19, 2023
Maintainer Author

#7641 Will help with that too by changing from a ?_data={routeid} param to the {url}.json extension. Then you can write a simple script to pre-generate all the json files in public at the URLs the remix runtime will request them.

sergiodxa Oct 19, 2023
Maintainer

Yes, a combination of both HTML and the JSON will make this simpler.

ryanflorence Oct 19, 2023
Maintainer Author

Yeah exactly. #7641 is critical here not just for the file extension but the coupling of documents and json makes it all so much more simple (for remix and consumers):

import path from "path";
import { createRequestHandler } from "@remix-run/server-runtime";
import * as build form "./build"

let handler = createRequestHandler(build);

let hrefs = ["/", "/about", "/contact"];

for (let href of hrefs) {
  let [html, json] = await Promise.all([
    handler(href).then(r => r.text()),
    handler(href + ".json").then(r => r.json())
  ]);

  if (href === "/") href = "index"

  await fs.mkdir(path.dirname(href), { recursive: true});
  await Promise.all([
    fs.writeFile(html, `public/${href}.html`),
    fs.writeFile(html, `public/${href}.json`)
  ])
}

console.log("Remix SSG ...");

Now browsers and the client side remix runtime will request files that will be served straight out of public/.

sergiodxa Oct 19, 2023
Maintainer

Something nice is that you can still have a mix of static and dynamic ones, build /articles/123 Remix will still handle /articles/456.

rowanc1 Nov 8, 2023

This is awesome and exactly what we are doing in https://mystmd.org for static site generation for scientific papers. We are currently stuck on v1.17.0 because we are generating these assets and then changing some of the base-paths manually so that they can be deployed on GitHub pages (or in other static folders where additional url folders are put in). There was a change in #6409 that infinitely reloads the page when the path doesn't match the original.

Hopefully this can take that use case into account, allowing us to deploy simple remix sites that can load JSON and deploy to github pages!

grabbou · 2023-10-21T18:03:11Z

grabbou
Oct 21, 2023

Have you considered sticking to loaders and actions instead of introducing clientLoader?

Remix could take your loaders and actions, generate a backend and expose these via an endpoint. Then, in the client bundle, we could substitute that with fetch call behind the scenes. This would essentially make it unnecessary to define both clientLoader (with only purpose to fetch data from an endpoint) and separate resource route (to return an actual data from the server).

I was experimenting with that approach before and I have a POC ready. I was initially working on it as a part of my research bringing RSC and Server Actions into non-server targets (such as React Native). Happy to send you some more information or demonstrate it.

3 replies

sergiodxa Oct 21, 2023
Maintainer

Remix could take your loaders and actions, generate a backend and expose these via an endpoint

This already happens, if you have a route file like routes/admin.users.tsx the loader and actions will be available under /admin/users?_data=routes/admin.users.\

Then, in the client bundle, we could substitute that with fetch call behind the scenes

This is also what happens right now? Remix replace your loader and actions with a RR one that just fetch your server loaders and actions.

The purpose here is to let you control this.

This would essentially make it unnecessary to define both clientLoader (with only purpose to fetch data from an endpoint) and separate resource route (to return an actual data from the server)

You don't need to define a separate resource route in Remix, and this won't make you do it too, you still have loader and action for the server and clientLoader and clientAction for the browser.

grabbou Oct 22, 2023

Got it, thanks for clarification.

What happens in traditional Remix application when page is being loaded? My understanding was that loaders run on the server and response is streamed to the client - there’s no “fetching” per se.

In that sense, I get the distinction between loader and client loader and I find it quite smart that you can explicitly await server loader from the browser (alongside other stuff you may want to do).

I think given other targets and interoperability between them, it makes sense to have clear distinction between client and server.

sergiodxa Oct 23, 2023
Maintainer

What happens in traditional Remix application when page is being loaded? My understanding was that loaders run on the server and response is streamed to the client - there’s no “fetching” per se

You (the app developer) don't fetch it, but a fetch is happening, it's just happens that Remix is the one doing it for you, otherwise there would be no way (aside of doing a document request) to get a route loader's data.

You could say a client loader/action has always existed, but it was just doing a fetch to the correct server loader/action, now you will be able to provide your own client loader/action and decide when to fetch the server one, or even don't do it.

ryanflorence · 2023-11-06T17:59:12Z

ryanflorence
Nov 6, 2023
Maintainer Author

Michael and I bike-shedded a bit here, thinking maybe just do a boolean since "spa" is a muddy term.

ssr: false

We'll also want vite build --ssr to throw if set to false.

1 reply

sergiodxa Nov 7, 2023
Maintainer

Why the flag then? If Vite already has --ssr couldn't use default to SPA target unless SSR is enabled?

romansndlr · 2023-11-07T19:28:46Z

romansndlr
Nov 7, 2023

OK, so I'll write down my problem and someone smarter please tell me if this proposal solves it.

I have a Remix app that I want to wrap inside a native shell using Capacitor.js and distribute it to the app stores.

Capacitor supports a server url option but if you enable it, all the assets don't get bundled on the device.

This causes apple to decline the app from the store saying that there isn't a big enough difference from the web version.

If the server url option is off, Capacitor looks for an index.html file in the public directory.

So in a dream world for me, if you set ssr: false in your Remix config, the build ignores entry.server and the root route?! And supports some way for you to have an index.html file that points to your static assets?

I don't really know if it can work like this but if someone has and idea, I think being able to move between ssr and no ssr with the same codebase would solve a lot of problems.

7 replies

yimingjfe Dec 6, 2023

@sergiodxa Is there more information about "generate the index.html based on your root.tsx at build time"? I don't see it mentioned in the discussion, so if you do, please point me to it, thank you very much!

hoffnung8493 Jan 6, 2024

@romansndlr Try React Native's webview instead of Capacitor. I used to use Capacitor a lot, and got into the exact same issue when I used Remix with Capacitor. Not only does RN have more and better maintained libraries, u dont have to go with the unrecommended serverUrl method with Capacitor. Now I have a admin web app, mobile app and the "backend" running in a single remix codebase!

tbscode Mar 5, 2024

Anyone having success here?
Having a SSR remix app + SPA capacitor mobile app in one code base would be incredibly nice!

( I know that I can use clientLoader only and still get SSR but that has other drawbacks as request aren't made on the server anymore and I also cannot await serverLoader anymore )

I think having the option to suppress build errors that are raised then using loader or action with ssr: False would be really cool. @hoffnung8493 Capacitor offers so many native integration that just work cross platform so I don't see React Native webview as a satisfying alternative.

hoffnung8493 Mar 10, 2024

@tbscode For me, the number one requirement was to run Remix with normal SSR on mobile webview. This would be a single codebase for both web and mobile. With ssr: true, you suddenly need a separate backend. And to keep it simple, u might even have to use SPA mode for the web app, or u have duplicate backend code.

I have been using Capacitor for many years. With Capacitor to have this true single codebase working, I need to enable server.url, where I pass in the production url of the Remix app. But after recent update, it seemed like server.url cannot be used in production. Unlike before, in iOS, if u enable server.url, the url tab at the top is no more hidden. Maybe there is a way to hide it, but I couldnt find it. Also, the bluetooth packages with Capacitor didnt work well.

So I was kind of forced to try out RN. Bluetooth problem was immediately resolved with RN. I think RN has a bigger community, eco system etc. Since the RN webview can communicate with RN native app, u get access to all their RN packages, which in general I think are better maintained. Also, u can run Remix with SSR, cuz u can just provide the production remix app's link to the RN webview (instead of localhost).

And on top of that Expo was an amazing dev experience.

tbscode Mar 10, 2024

@hoffnung8493 no this is exactly what I'm trying to avoid.
I the whole app to be statically bundled when and that should then be served from the capacitor web view.
I would like the app to have an 'offline' mode, this I've managed to achieved in the past using redux + capacitor + webpack.

It would still be fine if request are routed though a deployed remix server if internet is available, but the assets should be bundled within the app.

And this does seem to be achievable with ssr: false, the index.html seem to be render-able without server access, but I cannot use the same code-base as for my web-deployment I'd like to use loader functions, which now raises an exception when 'switching' from ssr: true -> ssr: false.

So to truly have only one code base for my web deployment and the offline compatible mobile app, I'd need a way to ignore that exception or toggle use of loader functions.

donaldpipowitch · 2023-11-08T05:44:24Z

donaldpipowitch
Nov 8, 2023

If I understood the proposal correctly just a single HTML file will be generated, correct? Are there plans to create multiple entry HTMLs at some point (to support different initial prerendered layouts) which all act as a valid starting point for the same SPA?

0 replies

bbonamin · 2023-11-13T14:41:13Z

bbonamin
Nov 13, 2023

If I understand correctly, this would allow Remix to be used as-is in browser extensions, which require all templates to be bundled! Great!

0 replies

patryk-smc · 2023-11-19T12:03:56Z

patryk-smc
Nov 19, 2023

Would it be possible to have SSR for the initial page load and switch to a single-page application (SPA) approach for subsequent navigations?

Our site works as follows: Initially, upon visiting our website, a server-side request to our API fetches the necessary data to render the page. As users browse the site, they directly retrieve additional data from the API, bypassing the server for these subsequent requests.

3 replies

gustavopch Nov 19, 2023

Isn’t that just what Remix already does?

sergiodxa Nov 19, 2023
Maintainer

Yes, but I think he wants to show going to the loader again, this will be possible with client loader and clientAction.

patryk-smc Nov 19, 2023

You're right. It seems that this is already possible. Pardon me!

universse · 2023-11-29T07:03:04Z

universse
Nov 29, 2023

Will this and other proposals support having a mix of static routes and SSR routes?

for 'spa' mode, individual routes can opt-in to SSR mode.
likewise, for 'ssr' mode, individual routes can opt-in to prerendering.

What about mostly static, prerendered routes with some SSR sections? (eg product page with personalized recommendation)

0 replies

yimingjfe · 2023-12-06T07:23:01Z

yimingjfe
Dec 6, 2023

Will the root route only render on the browser side?

This means that when the project changes from spa mode to ssr mode, I'll have to do some modifications to the root and entry.

0 replies

brophdawg11 · 2023-12-13T18:02:43Z

brophdawg11
Dec 13, 2023
Maintainer

The HTML entry point for vite is defined at app/entry.html with a script pointing to entry.client.tsx:

Does the root.tsx file get ignored in SPA mode? Or is it expected to only return the contents of <div id="app">?

I was actually sort of envisioning a world in which we render the Root component at build time and dump the output into index.html. That has a few benefits:

User's can still manage things in the <head> with React and leverage <Meta/>/<Links/> from Remix
<Scripts> would handle rendering the proper build assets with content hashes
Users can control loading behavior via clientLoader and HydrateFallback in root.tsx
No changes needed to root.tsx to move from SPA to SSR mode

It might veer a bit off from standard vite SPA practice though where the user manages a raw HTML file.

1 reply

brophdawg11 Dec 14, 2023
Maintainer

This sort of "just works"™️ from a very quick test today:

Use only clientLoader's in your routes
Stick a HydrateFallback in root.tsx (should include <Scripts> and probably <Meta>/<Links> too if you're using them in your routes)
npm run dev
curl http://localhost:3000/ -o public/index.html
stop dev server
npx http-server public
Load up http://localhost:8081/

ngbrown · 2023-12-15T18:29:04Z

ngbrown
Dec 15, 2023

I read this proposal as primarily having the motivation for ease of migration from React Router SPA to Remix SPA, and eventually to Remix SSR.

In the case of servers where a JavaScript backend isn't possible (e.g. GitHub Pages), I think the Remix documentation should have some guidance for new applications to help them make a choice between React Router SPA and Remix SPA. What are the advantages and disadvantages of starting with one over the other?

4 replies

brophdawg11 Dec 15, 2023
Maintainer

eventually to Remix SSR

This is not everyone's goal (nor should it be) - you can stop at Remix SPA

React Router SPA and Remix SPA

There shouldn't be any functional difference. Remix SPA is just RR SPA with an included Vite plugin for file-based routing. Only reason I could see to recommend RR at that point is wanting to use something other than Vite

cmacdonnacha Dec 23, 2023

Are there any other reasons to use Remix SPA over RR + Vite?

sergiodxa Dec 23, 2023
Maintainer

@cmacdonnacha you get the file convention from Remix so you don't need to create your routes config yourself, also if you later plan to enable SSR it's just one config and you can start using it, you may also get other features like <Link prefetch> (only available in Remix and not in RR)

brophdawg11 Jan 3, 2024
Maintainer

With Remix SPA, you also will be hydrating the document by default (but don't have to) and therefore you get access to Remix's <Links>/<Meta> components/functionality and don't need to reach for something like react-helmet.

AsuraKev · 2023-12-17T19:03:01Z

AsuraKev
Dec 17, 2023

Missing features like SPA mode + Module federation is why I am looking at Modern JS framework otherwise I ll be using Remix all the way :)

0 replies

jrestall · 2023-12-20T22:05:10Z

jrestall
Dec 20, 2023

We use Vite's library mode to distribute our React Router SPA, rather than an index.html. This is so that the app can be embedded within other sites.

Would the following be possible?

// vite.config.js
import { resolve } from 'path'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [
    remix({
      target: "spa",
    }),
  ],
  build: {
    lib: {
      entry: resolve(__dirname, 'src/app/entry.client.tsx'),
      name: 'MyApp',
      fileName: 'my-app',
    },
  },
})

6 replies

brophdawg11 Jan 3, 2024
Maintainer

Interesting idea - I'll bring it up internally for discussion. At the moment, the way I'd recommend doing it is with a small post-processing step to extract the <script> contents of index.html into an index.js file - they'll have exactly what you need and avoid needing any custom stuff in entry.server since you are leveraging <Scripts> directly via the <RemixServer> render.

jrestall Jan 4, 2024

Thanks @brophdawg11, embedded react widgets and using react for part of an existing page is a common way to use react and react-router as documented at https://react.dev/learn/add-react-to-an-existing-project#using-react-for-a-part-of-your-existing-page so I'm hopeful this can be supported.

brophdawg11 Jan 16, 2024
Maintainer

@mjackson and I talked a bit more about this and I think we're going to skip bringing this over as a first class API.

Remix SPA Mode is really just a higher level abstraction around React Router + Vite that brings along a few goodies:

Filesystem routing
Full-document hydration + <Meta>/<Links> support
You are now 1 small config change away from opting into SSR on a route-by-route basis

The concept of "library mode" negates (2) and (3) if you don't manage the HTML and have no interest in SSR so it's likely better to stick to the lower level APIs (RR + Vite) for that use case. You can also build (1) in userland without too much work as a vite plugin (some folks already have). I don't think there's anything else you'd be missing out on using RR/Vite directly, right?

This also helps us keep the surface area manageable from a documentation/communication standpoint.

brophdawg11 Jan 16, 2024
Maintainer

That said if you write the code required to do what I suggested in #7638 (reply in thread) please post it here for other that may be interested in this approach!

jrestall Jan 18, 2024

Thanks @brophdawg11 , really appreciate you considering this and doing the POC.

We share feature code between our legacy websites that are incrementally modernizing onto RR 6 + Vite and our modern sites that are on Remix, so I'll look into your suggestion as having everyone on Remix using the same conventions and imports would simplify things.

joseph-lozano · 2024-01-06T02:33:19Z

joseph-lozano
Jan 6, 2024

Sorry if this is a silly question but will API routes still work with in SPA mode?

3 replies

sergiodxa Jan 6, 2024
Maintainer

RR allows routes without components so resource routes will most likely keep working, just that client side

They can be useful for using them together with useFetcher

joseph-lozano Jan 10, 2024

I tried out the preview yesterday. It worked in dev mode, but build did not work.

brophdawg11 Jan 10, 2024
Maintainer

If you mean "API routes" as in server resource routes, then no - those will not work in SPA mode since SPA mode doesn't have a server.

You can do a client-side resource route with a clientLoader though, just as you would in a React Router app:

// routes/api.tsx
export function clientLoader() {
  return "API ROUTE DATA";
}

Fireclunge · 2024-01-12T15:10:05Z

Fireclunge
Jan 12, 2024

The route module API remains the same, but the loader and action exports will be ignored, and only the clientLoader and clientAction exports will be used.

Exporting server loaders in SPA mode now raises a breaking error.

Is it possible to have loaders be truly ignored (via a warning or optional flag) and have useLoaderData() return undefined or an empty object as I think this could be really useful for exporting on to mobile with capacitor.

I.e. I want SSR & loaders for the website but have have an SPA for mobile use - I can handle the gathering of loader data client side seperately but breaking loaders appears like it would require a big rewrite.

11 replies

Fireclunge Feb 6, 2024

I love the work that you guys are doing and really appreciate the help you've given but there's multiple people in this thread showing an interest in having an SPA packaged mobile app with the full strength of the SSR for a web deployment. To what extent does this remain an edge use case.

Here's my use case. I use react query to gather data for a given page. I populate its initialData input with data from SSR loader functions giving SSR rendered information from the get go. However by just ommiting loaders (for an SPA version) all that would happen is that initial loading spinners would show up briefly for a mobile app which is exactly what I would want to give the impression of a quick initial load (dataless ofc) with an indication to the user of a backend ping while making it more viable for app store reqs.

hoffnung8493 Feb 7, 2024

I had a very similar problem. I used to build a single web app for iOS, android and also the web. So I used to build mobile apps with SPA and Capacitor. While the Capacitor guys do say that u can not get app store approvals, by using serverUrl, I completely disagree. I have shipped multiple apps with Capacitor and the deployed SPA's domain (not localhost, but the actual url). People say ur app can get disapproved if its just purely a webview, but just adding push notification clears that issue.

Last year, I tried Remix (standard already deployed Remix) with Capacitor (serverUrl). For some reason it didnt work well on iOS, when serverUrl was enabled, the url tab of the webview, which is ok for debugging purposes, but unacceptable for production deployment. I think they have updated Capacitor to make this hard or I have done something wrong.

Anyway I tried a few days and decided to give React Native's webview a try. I would just make a very simple RN app with a webview and provide the production Remix URL to it. It worked flawlessly and I had a lot more control. Its not a hacky way like serverUrl in Capacitor. Also RN and webview can communicate, so u can also use all the native features from RN such as push notification, bluetooth connection etc. In fact, the dev experience was so much better with RN and Expo compared to Capacitor. I always thought Capacitor would be better in such use case, cuz Capacitor is made for SPAs, but to my surprise, RN with Expo was a lot better. At least for my use case, I didnt have to touch any mobile native code. Also the native plugins were better maintained than the ones for Capacitor. (I had so much struggle setting up bluetooth with Capacitor, but was a breeze with RN library)

Also what Capacitor maintainers say about App Store disapproval does not make any sense to me. They say u need to include the SPA build (js, css, html) in the native mobile app then run it locally inside the app (localhost). If u dont and just use a production url without storing any of the build code in the mobile app, there is "security issue", cuz u can change the deployed SPA without going through app store approval. BUT, even if u have all the build files installed in mobile app, u can still update those files without going throghh app store approval!! U can use their Appflow service, to update those build files. So for app stores, it makes no difference weather u store ur build files in ur app or just a link to the production web app. My guess, why they actually try to push SPA builds is cuz if users just use serverUrl, people will stop using Appflow, which is their main business model!

So my suggestion is to use plain Remix with RN's webview. Single codebase for iOS, android and web. You can still use all the loader, actions etc, no need to switch to SPA just because u want to deploy to mobile. So ur Remix configuration becomes simple as well. You dont have to conditionally use SPA mode or rely on client action/loader in mobile and use SSR mode with loader/action for web. Only use SPA if u really need SPA, for example u have a python backend, graphql backend that is already production ready etc.

WillSmithTE Feb 7, 2024

@hoffnung8493 this is really interesting to me, I've also been down this path of capacitor vs react native vs webview (vs PWABuilder as well).

How did you go getting offline navigation working with the remix app in webview?

hoffnung8493 Feb 7, 2024

I have not tried offline navigation, my app requires internet connection. But I think there are a few things u can do. First of all ur mobile app shell is in RN. So u have full control of the webview, which means u can render the webview component conditionally, only when internet connection is available. If not, you can show a simple RN page with the warnings. If your Remix app has offline functionalities, maybe its possible to cache all the frontend code on initial load. I suppose when user first installs the app, most likely they will have internet connection on the initial app start, right after the installation. But I am not sure about this.

If ur app is purely offline, then I think it makes more sense to build the remix app in SPA mode and store the build with the native app just like Capacitor's approach

WillSmithTE Feb 7, 2024

ah fair enough, that was what i'd come to as well.

i'm sure it's possible to get a full remix ssr app which caches loader data to use if there's an error fetching, similar to react-query marking things as stale but keeping them in the cache potentially indefinitely. my app is used where there isn't great internet connection, so i need really smooth switches between online/offline. just waiting for someone to build an awesome example of it

brophdawg11 · 2024-01-16T22:32:55Z

brophdawg11
Jan 16, 2024
Maintainer

Released in 2.5.0 - should flip to stable in the next release or two: https://github.com/remix-run/remix/blob/main/CHANGELOG.md#v250

0 replies

AYastrebtsov · 2024-01-26T15:03:24Z

AYastrebtsov
Jan 26, 2024

Hi everyone! Can somebody clarify for me please?

In February I am going to start develop a new project. It HAS to be an SPA.
We've done a few SSR projects in our company with Remix and we are totally loving it!

For SPA we used React Router + TanStack Query.

But now I see that there is SPA Mode and clientLoaders and clientActions in Remix.

We would love to unify our DX, It would be sooo great if we could use Remix and the same mindset for SSR and SPA projects.

So far I understand this:

clientLoader and clientActions are stable and can be used.
How risky it is, to start this project with Remix SPA and Vite? From this RFC is seems that Remix SPA it pretty stable, or am I wrong?

Development of this project will take 2-3 months I guess, and we would really like to start this project with Remix SPA. More than that, Vite fixes all problems which we had with our UI library of choice - PrimeReact.

We love Remix very much, thanks everyone for such a great framework, from Russia with love, Andrey.

4 replies

aarjithn Jan 26, 2024

Related, I would love to have next Remix single to be on SPA mode. Please make it happen @ryanflorence and co.

We have many documentation around "standard" remix, but how we can use SPA mode is very 'underexplored'.

brophdawg11 Jan 29, 2024
Maintainer

Remix SPA will very likely "stabilize" when the Remix vite plugin stabilizes, which is close. We won't commit to any hard dates but it's getting closer every day.

That said, we should be clear what unstable_ means here too. It does not mean "full of bugs" - rather we believe the APIs are well tested, production ready, and without known bugs. The unstable_ prefix only means that there could be small breaking changes to the API in subsequent minor releases as we receive more and more feedback from early adopters. These types of breaking changes will always be called out in release notes, so as long as you're reading release notes closely upon upgrading versions and are not opposed to having to make a few small changes here and there to any unstable_ APIs - then there's no reason not to start your new project in Vite + SPA Mode IMO

AYastrebtsov Jan 29, 2024

Thanks for clarification! We'll start our project next week. Happy to be early adopter this time, and will be glad to be of any help!

mhmdjaw Feb 21, 2024

Theyy just released the stable version of remix vite (including SPA mode)!!! Check their blog. If you already started your project with the unstable version you can easily update to the stable one now!

🗺️ Remix SPA Target #7638

ryanflorence Oct 11, 2023 Maintainer

Remix SPA

Proposal

Entry points

Migrating from SPA to SSR targets

Replies: 21 comments · 52 replies

ryanflorence Oct 12, 2023 Maintainer Author

sergiodxa Oct 19, 2023 Maintainer

ryanflorence Oct 19, 2023 Maintainer Author

sergiodxa Oct 19, 2023 Maintainer

ryanflorence Oct 19, 2023 Maintainer Author

sergiodxa Oct 19, 2023 Maintainer

sergiodxa Oct 21, 2023 Maintainer

sergiodxa Oct 23, 2023 Maintainer

ryanflorence Nov 6, 2023 Maintainer Author

sergiodxa Nov 7, 2023 Maintainer

sergiodxa Nov 19, 2023 Maintainer

brophdawg11 Dec 13, 2023 Maintainer

brophdawg11 Dec 14, 2023 Maintainer

brophdawg11 Dec 15, 2023 Maintainer

sergiodxa Dec 23, 2023 Maintainer

brophdawg11 Jan 3, 2024 Maintainer

brophdawg11 Jan 3, 2024 Maintainer

brophdawg11 Jan 16, 2024 Maintainer

brophdawg11 Jan 16, 2024 Maintainer

sergiodxa Jan 6, 2024 Maintainer

brophdawg11 Jan 10, 2024 Maintainer

ryanflorence
Oct 11, 2023
Maintainer

Replies: 21 comments 52 replies

ryanflorence Oct 12, 2023
Maintainer Author

sergiodxa
Oct 19, 2023
Maintainer

ryanflorence Oct 19, 2023
Maintainer Author

sergiodxa Oct 19, 2023
Maintainer

ryanflorence Oct 19, 2023
Maintainer Author

sergiodxa Oct 19, 2023
Maintainer

sergiodxa Oct 21, 2023
Maintainer

sergiodxa Oct 23, 2023
Maintainer

ryanflorence
Nov 6, 2023
Maintainer Author

sergiodxa Nov 7, 2023
Maintainer

sergiodxa Nov 19, 2023
Maintainer

brophdawg11
Dec 13, 2023
Maintainer

brophdawg11 Dec 14, 2023
Maintainer

brophdawg11 Dec 15, 2023
Maintainer

sergiodxa Dec 23, 2023
Maintainer

brophdawg11 Jan 3, 2024
Maintainer

brophdawg11 Jan 3, 2024
Maintainer

brophdawg11 Jan 16, 2024
Maintainer

brophdawg11 Jan 16, 2024
Maintainer

sergiodxa Jan 6, 2024
Maintainer

brophdawg11 Jan 10, 2024
Maintainer