3 ms·

> Your Ember app will behave no differently than server-rendered apps when it comes to search engines, mobile users, cURL, or users with JavaScript disabled. H

> Your Ember app will behave no differently than server-rendered apps when it comes to search engines, mobile users, cURL, or users with JavaScript disabled. How are Javascript disabled users going to use the app? Unless the app consists text and links, all interaction like submitting a form is usually coded with the idea that an ajax request will be made instead of a form submission triggering a page refresh. react-router is React's most popular router component (which is inspired by Ember's routing system) just delivered a solution for server-side rendering a few weeks ago. My app can now deliver the fully rendered html from the server and the server also can "fetch the models" when preparing the html. However, if the user is quick (or their internet connection is slow) and tries to submit a form before React had a chance to "rehydrate" it won't work. Sure links work just fine but none of the bits that require my app to be running will work which is significant portion of most applications designed around React, Angular, Ember, etc. For now, either we go back to spinners (which won't stop spinning if you've got JS disabled) or design the whole app with JS-disabled users in mind which would mean a lot of duplicate effort by having two possible endpoints for submitting forms; ajax-returning endpoints and traditional POST request endpoints which would return a redirect or a full page of html with validation errors included.

insin 12y ago
I have form submission and redisplay with and without JavaScript on the client working with my React forms library (newforms) and react-router. The server version funnels POST bodies through the same willTransitionTo hook that the client uses for form submisson. Superagent is used within the hook to attempt submission to the same API route in both environments and redisplay is done by rendering a full page on the server, or emitting errors from the API via an EventEmitter on the client, all with the same React component. User input, validation errors and any other data required to render the server version are made available for the client version to rehydrate from at any time it's able to. There are still some bits which feel (and are) hacky, but it works - details here: https://github.com/insin/newforms/issues/55#issuecomment-67756422 https://github.com/insin/newforms/issues/55#issuecomment-677...
- xtrumanx 12y ago
  Wow, really. That's awesome! My initial happiness when I got server-side rendering working complete with ajax calls on the server was short lived once I realized none of my forms worked until React had chance to load and run. I'm really glad someone else out there has noticed this issue and is attempting to tackle it. Although I was hoping I would still have control of how I build my forms while I do it. Do you think it would be possible to separate the form submission and redisplay functionality from the widget library part of newforms?
  - insin 12y ago
    The important part for making it isomorphic is the data flow - you could use any component which can populate its form fields and error messages from props on initial render. The express middleware [1] which uses your react-router routes just handles getting data to the right place. [1] https://github.com/insin/isomorphic-lab/blob/master/src/react-router-middleware.jsx https://github.com/insin/isomorphic-lab/blob/master/src/reac...

insin 12y ago

I have form submission and redisplay with and without JavaScript on the client working with my React forms library (newforms) and react-router. The server version funnels POST bodies through the same willTransitionTo hook that the client uses for form submisson. Superagent is used within the hook to attempt submission to the same API route in both environments and redisplay is done by rendering a full page on the server, or emitting errors from the API via an EventEmitter on the client, all with the same React component. User input, validation errors and any other data required to render the server version are made available for the client version to rehydrate from at any time it's able to. There are still some bits which feel (and are) hacky, but it works - details here: https://github.com/insin/newforms/issues/55#issuecomment-67756422 https://github.com/insin/newforms/issues/55#issuecomment-677...

xtrumanx 12y ago
Wow, really. That's awesome! My initial happiness when I got server-side rendering working complete with ajax calls on the server was short lived once I realized none of my forms worked until React had chance to load and run. I'm really glad someone else out there has noticed this issue and is attempting to tackle it. Although I was hoping I would still have control of how I build my forms while I do it. Do you think it would be possible to separate the form submission and redisplay functionality from the widget library part of newforms?
- insin 12y ago
  The important part for making it isomorphic is the data flow - you could use any component which can populate its form fields and error messages from props on initial render. The express middleware [1] which uses your react-router routes just handles getting data to the right place. [1] https://github.com/insin/isomorphic-lab/blob/master/src/react-router-middleware.jsx https://github.com/insin/isomorphic-lab/blob/master/src/reac...