search

mitodl / micromasters

Portal for learners and course teams to access MITx Micromasters® programs
https://mm.mit.edu
BSD 3-Clause "New" or "Revised" License
30 stars 17 forks source link

enable full route-based splitting #3017

Open alicewriteswrongs opened 7 years ago

alicewriteswrongs commented 7 years ago

As explained in #2163 we set up webpack to split the JavaScript into separate bundle files based on routing, so that the JavaScript which is unique to every route would go into a separate file just for that route, and the user would only need to download a minimal amount of JS for each route (the common.js bundle and the per-route file).

Unfortunately, the default user experience for enabling this for every route is a little less than great. On a fast connection it's quite nice - clicking a react-router link to go to a new route fires off a request which downloads the JavaScript for the next route, and when that request comes back that JavaScript file is parsed and the new view is rendered. This is pretty fast on a fast connection, so there isn't much in the way of a noticeable lag.

On a slow connection, however, there is a noticeable lag between when the request for the next bundle is initiated and when it comes back. The user doesn't see any indication of what is happening, until the request comes back and the UI transitions to the new view. In the gap between those events the user can still interact normally with the UI, potentially initiating requests for other views, clicking on things, etc and then when the first request comes back they are somewhat abruptly switched to the new view.

So! Long story short, it would be good to enable full route-based splitting in production. Currently we only split the /learners route out from everything else, so that for most pages there is still extra JavaScript being downloaded which is not directly necessary to render that page. If we implemented something which signalled to the user that the app was in the process of transitioning to a new page we could enable the full route splitting, so that there would be a separate bundle for each route (e.g. /dashboard, /profile/personal, /settings, etc). This would certainly give us a boost to page-load times, but we should do some thinking first about what would be the best possible UX.

I have some ideas, like maybe the whole app gets greyed out and a spinner pops up in the middle of the page or something along those lines.

alicewriteswrongs commented 7 years ago

@roberthouse54 do you have any ideas for what the UX should be for this?

alicewriteswrongs commented 7 years ago

we're going to try out doing an opaque overlay with a spinner

pdpinch commented 7 years ago

I'm concerned that this could end up feeling worse than the current experience. (Have you tried LinkedIn lately)?

Is a spinner really better than just a plain old page load?

alicewriteswrongs commented 7 years ago

Something that feels like a normal page load would be good too - the problem with what we've got now it that isn't obvious anything is loading (as it is with a traditional full page refresh). The app looks totally normal and does not acknowledge the user has clicked a link, and in the background the JavaScript request goes off, and the page sort of suddenly redraws when it comes back.

pdpinch commented 7 years ago

I think we should take a step back and have a wider conversation. Maybe in a retrospective or over lunch.