single page application routes and dotcms

[monzonj]

Hello,

Modern web applications written in Angular / React or similar, use a client based routing system to present different views. In the case of angular, it's the @angular/router module.

These routes contain paths such as /product/[id], /client/[name], etc, in order for Angular/React to load any particular view. The browser search box is updated with these "fake" urls.

However this does not work when a single page application is deployed inside dotCMS. Because when angular set's the browser url to be, for instance /client/MY_CLIENT and the user refresh the page, dotCMS will return 404 because the page in the /client/ folder does not exists. 

This renders dotCMS unusable for single page applications

Is there a way to work around this issue?

Regards

Jose Monzon

[Maarten Daalder]

You can probably use a vanity url and forward to the actual page.

If you want to be really fancy then you can even parse the URL and prerender the page.

[Nathan Keiter]

You might be able to achieve this kind of behavior with a RESTful servlet. dotCMS makes it easy to make annotated RESTful endpoints. The information returned could be anything you want, whether data or page etc.

 

The only catch is that it must be under the /api/ prefix. So /api/products/product/{id} or /api/clients/client/{name}. Or one that does both /api/angular/product/{id}, /api/angular/client/{name} for example.

 

Another thing to look into would be URL Mapped Content pointing to a dynamic detail page.

 

Nathan I. Keiter | Lead Network Applications Programmer | Benefits Advisory Council Member | I.D.E.A Council Member
Gettysburg College | Information Technology | DataSystems
Campus Box 2453 | 300 North Washington Street | Gettysburg, PA 17325
Phone: 717.337.6993

https://www.gettysburg.edu

--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To post to this group, send email to dot...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/1d21ddce-e6c6-462d-a505-f7703f929ded%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Falzone]

We ran into this with out Angular Applications.  The main issue is that you need to have all traffic forwarded to the page where the SPA lives with a 200 response code.  The Angular History Model takes it from there.  The issue becomes clear when you try to integration something like Third-Party JWT authentication, Google oAuth, the Facebook API.  Anytime the user needs to leave your SPA and get redirected back.  This is where we ran into issues with the response code.

We have 2 solutions currently in the works:

1) In the past we used our Load Balancer to do the proper forwarding.  We don't use this anymore as we are looking to phase out our software LB, but this has worked very well for us for some time.

2) We now use CloudFront Distributions to front-end all of our Angular SPAs. (Whether or not they are hosted in dotCMS.)

The tricky part in regards to a dotCMS-only solution is that (1) it has to have a 200 response code not a 40X/30X, and (2) you want one wildcard rule so you don't have to manage multiple forwards for each path in your router.  Because of (1), Vanity URLs in 4.1.1 will NOT work here, I tried.  In 4.1.1, the answer to this problem would be a very simple URLRewriteFilter Rule; however there is in an issue in dotCMS 4.1.1 that makes URLRewriteFilter forwards not work (multiple github issues have been logged about this and there are work-arounds if you want to look them up).  So, barring hacky work-arounds, I do not know of a way to get this to work in 4.1.1 without front-ending it with something that can handle the forwarding like ngnix, cloudfront, or a load balancer.

This issue is possibly resolved in 4.2 with the new Vanity URL system (which can do forwards using regex).  I still have my doubts that Vanity URLs will work because you have to set the response code to 200 specifically, and I am not sure you can do that with the new system in 4.2.  I'd love to see some testing on it, specifically using some form of oAuth Authentication like google or facebook.  This is where I ran into the issue of needing the response code to be 200.  

Hope that helps.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/091c00e32e044018885ee6c714560c66%40exch13c.ms.gettysburg.edu.

[John Michael Thomas]

So the good news is that yes, in 4.2.x you can set the response code to 200 with the new vanity URLs.  You can also set up the vanity URLs to use regular expression matching so you could use a single vanity URL for multiple single-page app pattern matches.

Note also that the "traditional" way to handle single-page content in dotCMS is to use URL Maps.  I don't think that's what you want here (though you might be able to shoehorn it to work), but something to be aware of since URL Maps take multiple URLs and map them to a single page natively.