In a plugin, how can I force clients to re-load extra-locales file?

Dev
1

We’ve created a custom JS method for some custom locale work that loads the browser side I18n object with a custom attribute.

I want to trigger a re-evaluation of this JsLocaleHelper method on each of the dependent clients.

I’m trying to find a way to trigger this from server side.

This used to work but seems to have changed recently.

The data is correct when I delete the local client cache from the browser, but obviously this is not tenable for production use. It proves the issue is the local caching though.

Things I’ve tried include:

 Discourse.request_refresh!

or the more targetted:

Discourse.request_refresh!(user_ids: user_ids)

which appears to force refresh on navigate. However suspect the script is being cached so this is not a solution.

Any help appreciated!

1 Like
2

Note that this function behaves very differently when the user_ids parameter is present and when it’s not.

Did you try MessageBus.publish "/file-change", ["refresh"] ?

3 Likes
3

Excellent idea, that works! Thanks

But is it scalable?

2 Likes
4

Nope, I don’t think so :frowning:

2 Likes
5

That helps a lot though I will continue digging.

If I can find a flavour of that that spreads over time we may be good to go.

Although it would be nicer to target the exact file.

2 Likes
6

OK, so between a rock and a hard place here.

Here’s what I’ve learnt:

  1. The extra-locales bundles are added as script tags.
  2. They contain a version parameter that depends on the name of the bundle
  3. The version number is only evaluated at bootstrap I believe, so will remain cached until:
  • you force the clients to completely refresh, which can only apparently happen en-masse?
  • you restart the server
  • or a client clears their browser cache

This is unfortunate to say the least, that there is not more granular control.

  • Could we introduce a “total refresh” on nav message?
2 Likes
7

I just tested Discourse.request_refresh! and it does seem to be reloading all javascript assets on the next navigation. It might not be triggering a JsLocaleHelper refresh, I am not sufficiently informed on how that works.

8

There’s a subtle thing going on.

the “200” is actually “200 (cached)” which is browser side.

Good Stack Overflow post about it.

1 Like
9

Argh…:scream: … didn’t check that.

2 Likes
10

Did you try to call ExtraLocalesController.clear_cache! after you make changes to extra-locales? It should recalculate the version during the next request.

2 Likes
11

Thanks. Yes I have. I believe that’s just server side and does not change the version number on the provided JS file set up during bootstrap. Server side there is no issue.

I’m considering moving this data to the site object and serializer so see if I can have more control.

12

Well, I guess, I do not understand what you are trying to accomplish. :thinking:
I assumed you wanted client to simply pick up data you added on the server on next reload. If you want to do everything on the client, why not update I18n.extras directly on the client.

2 Likes
13

Yes, exactly this.

If I run that command from the rails console, how does it invalidate the scripts on the client?

(FYI tags are special case as are used in slugs, so I have to add a special object to include translations, I can’t serialize a tag translation everywhere as routes would not work).

14

Next time the client reloads the page it will see a different hash in the HTML and load the new script. That’s how the “Customize Text” feature (it uses the “overrides” bundle) works.

<link rel="preload" href="/extra-locales/overrides?v=ecb7809c205de318b2c16d1b51d4b6f6" as="script">
3 Likes
15

I’m able to repro that.

So I’m not using overrides for this as we aren’t talking about vanilla client side JS localisation.

For some reason the present use of our custom JsLocaleHelper file doesn’t hook into that version number update system.

But that’s extremely useful, thanks Gerhard, as I will be able to study how the server causes that version number to be updated.

I also note the overrides file is discretionary, interesting!

1 Like
16

@gerhard that was extremely helpful, thank you.

Issue resolved. I simply had to make sure the version number was based on the content of the custom js file. I now have it working in dev :rocket:

4 Likes
17

Full results of this conversation are implicit in this PR: Tag caching fixes by merefield · Pull Request #52 · paviliondev/discourse-multilingual · GitHub

4 Likes