Internet Explorer doesn't work when updating from Universal router 3.x to 4.x or 5.x

[antoninadert]

Server side rendering still works, but client-side rendering never happens (rehydration) on IE 11 after updating from 3.x to 4.x or more

Do you test on IE ?

[antoninadert]

By the way I don't understand the changes made since v3.2 ... for me these breaking changes add overall complexity to what was an elegent syntax

[frenzzy]

Just checked UniversalRouter v5 in IE9, IE10, IE11 and Edge. Works well! Demo page: https://frenzzy.github.io/test/universal-router

Have you read a section about browser support in our readme?

Universal Router supports all popular browsers, including Internet Explorer 9 and above with polyfills such as es6-shim for Map, Promise and Object.assign that must be included before any other code.

For compatibility with older browsers you may also need to include polyfills for Array.isArray and Object.create.

Also you may need to use IE compatible code, or transpile your code to ES2015 by Babel.

What exactly change you dislike since v3.2? I can explain...

[antoninadert]

Well your example is working on my machine, but my example no.

It is based on Meteor and I have core-js and babel-preset-env so I believe I have the necessary polyfills.

see it here: https://github.com/antoninadert/proto-starter

If you can install meteor you can give it a try.. I wish I had a server but not yet. If you open the demo you would see that when changing the name of Bobby, nothing updates (it should) so it just does like if no javascript was injected and only server side. But committing to the previous version of proto-starter works perfectly.

I dislike breaking changes when they don't bring real value to the table, and I didn't see it, but now I believe it helped other devs so it may be OK.

Talking about my dislike, for example the fact you don't support '*' for 404 and no '/' for home url (and I liked this simple syntax) , even if I get that you wanted to let more control and your solution is OK and more flexible.

I have a small project for now and I just found your solution to be elegant and pure when I joined in v3.2, now I find it more convoluted (but it may be more powerful).

It's just I don't need these new things at the price of additional complexity, and I don't understand the benefits for me. I am designing my project around simplicity, declarative and understandable code, if I don't have to learn regexp for a simple router it's better for me.

Anyway, it's not a bad thing to add new possibilities, I just dislike the fact it has an impact on what was cool. Your solution is still cool and I really like it, I think I complained too much because it didn't work on IE and I regret that

[antoninadert]

Hello,

I made it work on IE with version 6, I believe my problem was not directly linked to universal router but to the way I use it. I didn't return Router.resolve() and that's why I believe my render function was not behaving the same in some browsers.

My new code here that works just in case:

  import { hydrate } from 'react-dom';
  import createHistory from 'history/createBrowserHistory'
  import universalRouter from 'universal-router';
  const History = createHistory()
  const location = History.location
  import Routes from '/My/_Routes'
  const Router = new universalRouter(Routes);

  /*Renders initial HTML based on URL*/
  renderURL(location);

  function renderURL(location) {
    return Router.resolve({ pathname: location.pathname }).then(route => {
      //Renders our component according to the route
      hydrate(route.component, document.getElementById("app"));
      //META DEFINITION HERE
      document.title = route.title;
    });
  }

Thanks