Hi,

I have a React app deployed on DO’s App Platform. I am using React Router and I’m experiencing problems with my routes. The only route working fine is home (‘/‘), which I’ve specified in the component’s routes on Digital Ocean panel. All the other routes work only when I’m navigating to them as a link from home. For example if I navigate to /xyz which is liked from the homepage, it works. But if I refresh I get a 404. Same if I try to navigate to /xyz directly.

Anyone can help?

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
5 answers

Support for the catchall_document field was released yesterday, so you can make use of this now instead of error_document, and get 200 responses rather than 404s. Just be sure to upgrade to the latest doctl in order to make use of it; we haven’t yet added support to the UI for configuring this field.

Thanks @snormoredo . So is it a matter of days (not weeks) before you make the release? I’m asking because the custom spec yaml process is one I would rather avoid doing if you plan to release the solution in the app platform’s UI.

  • @bobr21 Support for catchall_document will be released for the API (and doctl) within days. Support for error_document and catchall_document via the UI has no specific timeline, but your feedback here helps, so we’ll consider prioritizing it and follow-up when we have more — stay tuned.

@bobr21 👋

This is a great question, thanks for asking.

If you’re deploying a web service, then routing works as expected because it’s handling incoming traffic on all sub-routes. If you’re deploying a static site SPA, then you’ll only have the index.html served to incoming requests to / but not the sub-routes.

You can configure error_document: index.html in your app spec, so that incoming traffic will be rewritten to index.html while still maintaining the request path. The caveat with error_document is that those requests will have the status code of 404, but the content will show your index document as expected. We’ll be introducing a new configuration called catchall_document soon, that will solve this problem without that caveat; where the status code will be 200 instead of 404 while still rewriting as expected.

We currently don’t support configuring error_document via the UI, so you’ll have to use doctl and a custom spec YAML for now. Your app spec might look like something this:

name: sample-html
static_sites:
- name: site
  github:
    repo: digitalocean/sample-html
    branch: master
  error_document: index.html

You can then submit it using doctl with:

doctl apps create --spec .do/app.yaml

After doing this, you can manage your app via the UI as usual, and your deploy-on-push configuration will continue working as expected.

Thanks for using the App Platform, and happy coding!

@snormoredo thanks for that.
But here’s something I can’t understand why is happening.
Another person from the community had his React & React Router app working fine without doing the doctl process or really anything else changed.

Here’s the app: https://github.com/bjarneo/cra-router-example

and the code: https://github.com/bjarneo/cra-router-example

What is he doing right or what I am doing wrong?

Update: Turns out he’s using a service worker and that made it work (but not in incognito). So, I guess the custom spec yaml is the only true option, especially for dynamic routes.

  • @bobr21 Thanks for pointing out the cra-router-example; it does seem to handle routes properly, but only if you visit the root first before any other sub-routes. If you try opening /about in an incognito window, you’ll see the generic 404 page rather than the React app. The reason for this is that it contains a Service Worker that configures offline capabilities and serves assets from the local cache (registerServiceWorker.js).

    I deployed a branch without registering the service worker: https://cra-router-site-sans-svc-worker-i682j.ondigitalocean.app/ — if you go to a sub-route, and reload the page, you’ll notice the generic 404 page.

    I also deployed it with error_document: index.html configured in the app spec (via doctl): https://cra-site-wo-svc-worker-w-rewrite-mgqq9.ondigitalocean.app — if you go to a sub-route, and reload the page, you’ll notice the React SPA this time, even if you go to a sub-route in an incognito window.

    • Thanks for your help @snormoredo.
      I’ll try the app spec way tomorrow.

      But just to clarify, you mentioned that if I deployed my app (my original one with the 404 routing problem) as a web service instead of a static site, the routing would work (even if I visited a sub-route incognito)?

      I mean, if that’s the easiest option, maybe why don’t I do that? Is there a doc explaining what’s the difference between the two?

      • @bobr21 Yep, if you deploy as a service component rather than static site, it will be running as a backend web service — always-running containers responding to incoming HTTP traffic on all sub-paths. I’ve got the CRA router example deployed here: https://cra-router-example-service-hg2r2.ondigitalocean.app/

        Just select “Web Service” during the app create workflow in the UI instead of “Static Site”, go with the defaults, and 🚀

        • @snormoredo I see. So what’s the difference (pros/cons maybe) making it a static site vs a web service?
          I can only see that if it’s web service, it’s billed for (if it’s a static site and you already have a backend component, it’s not).

          What are the other differences? I really can’t find any docs explaining the differences to be honest.

          PS: I really like the app platform and what you’re trying to do so I’m also trying to help (myself and others who may be running into the same problems)

          • Hi bobr21,

            I’d say the three main differences between hosting a frontend app as a Static Site vs a Web Service using App Platform are:

            • Control: On a web service you have more control over handling requests and responses (e.g. http codes, redirects, URL rewrites) while on Static Sites you have to work with or around the available settings (error page, catchall)
            • CDN out of the box: On Static Sites you’ll be taking advantage of the built-in CDN out of the box, while on a Web Service you have to make sure your requests are cacheable by the CDN.
            • Price: Some static sites are free see App Platform Pricing, while containers start at $5/mo.

@snormoredo Help !

I tried all your steps and it didn’t work.
I’m still getting a 404.

Here’s my app.yaml:

name: exerolas-front-rewrite
static_sites:
- name: site 
  build_command: npm run build && mv build _static
  github:
    repo: charisra/exerolas-front
    branch: main
    deploy_on_push: true
  error_document: index.html

which is on /src/.do/

Doing a doctl apps list returns all 3 of my apps, as expected (my frontend, backend and the newly created app spec one). So I would now expect it to be working.

I’m starting to become frustrated to be honest. Can I ask for some dev to do a screenshare so we can sort this out?

  • @bobr21 send me an email at the address in my Github profile and we can find some time.

    • I have to say a huge thanks to @snormoredo for helping me sort out the issue during our call.
      This the support you dream of when choosing a hosting provider.
      I’m extra happy for having the chance to help sort this issues for any person using the App Platform and make it a better, more robust product.
      Once the documentation is out, I bet other users will avoid having similar issues.
      Looking forward to seeing this platform growing and establishing itsself as one of the market leaders (if not the one).
      In the meantime, anyone attempting to use React Router can use this convo as a reference.

Submit an Answer