Semantic-UI-React icon-font issues when using React-Router and second level links

react
1

setup
Meteor 2.5.0 with React frontend
Semantic-UI-React (SUIR)
React-Router v6 (same issue with v5)

Issue
When loading the app on a second level link (i.e. http://localhost:3000/firstLevelPage/secondLevelPage), the icon-fonts are not loaded correctly.

The problem seems to be related to the relative paths to SUIR-icon-fonts:

@font-face {
  font-family: 'Icons';
  src: url("./themes/default/assets/fonts/icons.eot");
}

I placed the fonts into public/themes/default/assets/fonts/ which works fine on top level pages.

Fix attempt 1 It can be fixed by putting
<base href="http://localhost:3000/">
into the <head> of clients index.html. But obviously this wouldn’t work for deployment on various URLs.

Fix attempt 2 When creating a custom css-file and overwriting the paths with absolute paths, the fonts are displayed correctly. I.e.:

@font-face {
  font-family: "Icons";
  src: url("/themes/default/assets/fonts/icons.woff2") format("woff2");
}

But then there is still a lot of errors/warnings in the console.

Sandbox I’ve created a sandbox to reproduce this issue:
https://codesandbox.io/s/meteor-suir-reactrouter-issue-x8lm1

Here is a demonstration: https://gifyu.com/image/S2Rir

This is probably more related to SUIR and React-Router, but maybe someone around here has an idea about it. I do not get why this issue only appears in second level links. Thanks for your help!

2

We have also been encountering this issue since Meteor 1.9.1, all the way up till Meteor 2.2.1, too
(Our builds on 2.4 are still failing due to an issue mentioned in another thread, so we cannot fully confirm it not working on 2.4 as well)

The issue did not seem to have occurred in Meteor 1.6.0_1 (the version that was “started off” with, but has been a consistent thorn in our sides since then.

Sorry for bumping this old topic, but would anyone have an inkling on how to solve the issue as described in the original post?

3

Through a bit more research, we have found a proper fix based off Fix #1 as outlined in the original post.

A better fix would appear to be using JavaScript to dynamically parse and set the base href tag, as per this StackOverflow post:

For instance, we have ours set as so for now…

<head>
. . .
    <script>
        document.write("<base href=" + 'http://' + document.location.host + '/' + 'firstLevelPage' +">");
    <script>
</head>

Update:
Modified it to be closer to the second example provided in that link, to better handle in the event of usage with IE 11 (in an extremely unlikely instance, since we use Edge by default):

<head>
. . .
    <script>
        document.write("<base href=" + 
                        document.location.protocol + '//' + 
                        document.location.hostname + 
                        (document.location.port ? ':' + document.location.port : '') + 
                        '/' + 'firstLevelPage' +">");
    <script>
</head>
4

I also encountered this and fixed it by moving the semantic css file from out of the node_modules and into the client directory and then just linked it in the html with a <link> tag