Wie kann ich in einem Plugin Clients zwingen, die extra-locales-Datei neu zu laden?

Wir haben eine benutzerdefinierte JS-Methode für benutzerdefinierte Locale-Arbeiten erstellt, die das Browser-seitige I18n-Objekt mit einem benutzerdefinierten Attribut lädt.

Ich möchte eine Neubewertung dieser JsLocaleHelper-Methode auf jedem der abhängigen Clients auslösen.

Ich versuche, einen Weg zu finden, dies von der Serverseite aus auszulösen.

Dies hat früher funktioniert, scheint sich aber kürzlich geändert zu haben.

Die Daten sind korrekt, wenn ich den lokalen Client-Cache aus dem Browser lösche, aber das ist offensichtlich für den Produktionseinsatz nicht tragbar. Es beweist jedoch, dass das Problem der lokale Cache ist.

Zu den Dingen, die ich versucht habe, gehören:

 Discourse.request_refresh!

oder das gezieltere:

Discourse.request_refresh!(user_ids: user_ids)

was anscheinend einen Refresh beim Navigieren erzwingt. Ich vermute jedoch, dass das Skript gecacht wird, sodass dies keine Lösung ist.

Jede Hilfe wird geschätzt!

1 „Gefällt mir“

Beachten Sie, dass diese Funktion sich sehr unterschiedlich verhält, wenn der Parameter user_ids vorhanden ist und wenn er nicht vorhanden ist.

Haben Sie MessageBus.publish \"/file-change\", [\"refresh\"] versucht?

3 „Gefällt mir“

Ausgezeichnete Idee, das funktioniert! Danke

Aber ist das skalierbar?

2 „Gefällt mir“

Nein, das glaube ich nicht :frowning:

2 „Gefällt mir“

Das hilft zwar sehr, aber ich werde weiter graben.

Wenn ich eine Art davon finden kann, die sich mit der Zeit ausbreitet, sind wir vielleicht bereit.

Obwohl es schöner wäre, die genaue Datei anzuvisieren.

2 „Gefällt mir“

OK, hier stecke ich zwischen Fels und hartem Ort fest.

Folgendes habe ich gelernt:

  1. Die extra-locales-Bundles werden als Skript-Tags hinzugefügt.
  2. Sie enthalten einen Versionsparameter, der vom Namen des Bundles abhängt.
  3. Die Versionsnummer wird meiner Meinung nach nur beim Bootstrapping ausgewertet und bleibt daher bis zu folgenden Zeitpunkten im Cache:
  • Sie zwingen die Clients zu einem vollständigen Refresh, was anscheinend nur massenhaft geschehen kann?
  • Sie starten den Server neu.
  • Oder ein Client löscht seinen Browser-Cache.

Das ist, gelinde gesagt, unglücklich, dass es keine granularere Kontrolle gibt.

  • Könnten wir eine “vollständige Aktualisierung” bei der Navigationsnachricht einführen?
2 „Gefällt mir“

Ich habe gerade Discourse.request_refresh! getestet und es scheint, dass alle JavaScript-Assets bei der nächsten Navigation neu geladen werden. Es löst möglicherweise keine JsLocaleHelper-Aktualisierung aus, ich bin nicht ausreichend darüber informiert, wie das funktioniert.

Es gibt eine subtile Sache.

Das „200“ ist tatsächlich „200 (cached)“, was browserseitig ist.

Guter Stack Overflow-Beitrag dazu.

1 „Gefällt mir“

Argh…:scream: … habe ich nicht geprüft.

2 „Gefällt mir“

Haben Sie versucht, ExtraLocalesController.clear_cache! aufzurufen, nachdem Sie Änderungen an extra-locales vorgenommen haben? Es sollte die Version während der nächsten Anfrage neu berechnen.

2 „Gefällt mir“

Danke. Ja, das habe ich. Ich glaube, das ist nur serverseitig und ändert die Versionsnummer nicht in der bereitgestellten JS-Datei, die während des Bootstrap eingerichtet wurde. Serverseitig gibt es kein Problem.

Ich überlege, diese Daten in das Site-Objekt und den Serializer zu verschieben, um zu sehen, ob ich mehr Kontrolle habe.

Nun, ich schätze, ich verstehe nicht, was Sie erreichen wollen. :thinking:
Ich ging davon aus, dass Sie möchten, dass der Client die Daten, die Sie auf dem Server hinzugefügt haben, beim nächsten Neuladen einfach abruft. Wenn Sie alles auf dem Client tun möchten, warum aktualisieren Sie I18n.extras nicht direkt auf dem Client.

2 „Gefällt mir“

Ja, genau das.

Wenn ich diesen Befehl von der Rails-Konsole aus ausführe, wie werden dadurch die Skripte auf dem Client ungültig?

(Zu Ihrer Information: Tags sind ein Sonderfall, da sie in Slugs verwendet werden. Daher muss ich ein spezielles Objekt hinzufügen, um Übersetzungen einzuschließen. Ich kann nicht überall eine Tag-Übersetzung serialisieren, da die Routen sonst nicht funktionieren würden).

Wenn der Client die Seite das nächste Mal neu lädt, sieht er einen anderen Hash im HTML und lädt das neue Skript. So funktioniert die Funktion „Text anpassen“ (sie verwendet das „overrides“-Bundle).


<link rel="preload" href="/extra-locales/overrides?v=ecb7809c205de318b2c16d1b51d4b6f6" as="script">
3 „Gefällt mir“

Ich kann das reproduzieren.

Ich verwende hier keine Overrides, da wir nicht über die clientseitige JS-Lokalisierung von Vanilla sprechen.

Aus irgendeinem Grund wird die aktuelle Verwendung unserer benutzerdefinierten JsLocaleHelper-Datei nicht in dieses Versionsnummern-Update-System integriert.

Aber das ist äußerst nützlich, danke Gerhard, da ich untersuchen kann, wie der Server diese Versionsnummer aktualisiert.

Ich stelle auch fest, dass die Override-Datei diskretionär ist, interessant!

1 „Gefällt mir“

@gerhard das war extrem hilfreich, danke.

Problem behoben. Ich musste nur sicherstellen, dass die Versionsnummer auf dem Inhalt der benutzerdefinierten JS-Datei basiert. Ich habe es jetzt in der Entwicklung zum Laufen gebracht :rocket:

4 „Gefällt mir“

Die vollständigen Ergebnisse dieser Konversation sind implizit in diesem PR enthalten: FIX: Tag caching fixes by merefield · Pull Request #52 · paviliondev/discourse-multilingual · GitHub

4 „Gefällt mir“