Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.javascript > #4865

Re: datepicker mit lokaler Version

Show all headers | View raw

Jan Novak wrote:

> Am 10.04.2017 um 20:52 schrieb Thomas 'PointedEars' Lahn:
>>> Du solltest nicht bei Bibliotheken, die untereinander Abhängigkeiten
>>> haben, von verschiedenen Quellen einbinden. Entweder remote per URL ODER
>>> lokal mit relativem Verweis im Filesystem.
>> Unsinn.
> 
> Das hätte mich auch gewundert. Jedoch ist mir aufgefallen, dass einigen
> Bibliotheken Abhängigkeiten auf weitere Bibliotheken beinhalten.
> Wenn ich diese also Lokal einbinde, müssen die Abhängigkeiten wohl auch
> Lokal sein, oder nicht?

Nein, aber es hilft.  Vielleicht hat Gerome dies gemeint: Wenn Du lokale 
Versionen von Bibliotheken verwendest, dann sind diese nicht mehr mit 
entfernten Versionen anderer Bibliotheken, von denen sie möglicherweise 
abhängen (oder umgekehrt), synchronisiert.  Ändert sich das API einer der 
beiden, kann es sein, dass das Programm nicht mehr funktioniert.

Aber natürlich – und darauf bezog ich mich – ist es durchaus möglich, eigene 
Bibliotheken, die von fremden abhängen, zu verwenden, und es ist auch 
durchaus sinnvoll, die eigenen lokal und die entfernten an ihrem offiziell 
zu verwendenden Ursprungsort zu referenzieren: Ändert sich das API nicht in 
inkompatibler Weise und werden die fremden Bibliotheken von mehreren anderen 
Web-Applikationen referenziert, dann können die im Cache des Browsers des 
Benutzers gespeicherten Versionen wiederverwendet werden, was die Ladezeit 
verkürzt; und wenn die Version sich noch nicht in diesem Cache befindet, 
erlaubt das dann meist verwendete Content Delivery Network (CDN) einen 
schnelleren Download.

Es gibt aber auch einen Nachteil: Man macht sich von diesem CDN und damit 
auch von einer Internet-Verbindung abhängig.  Falls es sich um ein CDN 
ausserhalb des eigenen (V)LAN handelt, ist es deshalb sinnvoll, einen 
Fallback einzubauen, falls dieses einmal nicht verfügbar sein sollte.  Das 
geht, indem man testet, ob nach Laden der Bibliothek vom CDN signifikante 
verwendete Symbole verfügbar sind; falls nicht, lädt man die lokale Version:

  <script type="text/javascript" src="//cdn.example/lib.js?v=3.14"></script>
  <script type="text/javascript">
    if (typeof lib == "undefined")
    {
      var script = document.createElement("script");
      script.type = "text/javascript";
      script.src = "//foo.local.example/lib.js?v=3.14";
      document.body.appendChild(script);
    }
  </script>

Das lässt sich natürlich auch kapseln:

  (function () {
    var lib_version = "3.14";

    jsx.require(
      [["CDN:lib.js?v=${version}", "local:lib.js?v=${version}"]],
      function () {
        if (typeof lib == "undefined"
           || compare_version(lib.version, lib_version) < 1)
        {
          return;
        }

        // …
      }, null,
      {
        version: lib_version
      });
  }());

    [jsx.require() gibt es (siehe Signatur), aber es funktioniert derzeit
     anders.  Ich arbeite noch daran, dass das in JSX tatsächlich so wie
     hier beschrieben funktioniert – zur Zeit habe ich andere Prioritäten. 
     Es erscheint nämlich – auch angesichts des inzwischen weithin
     unterstützten, verwendeten, *standardisierten* und *mit Events
     versehenen* Nachladens von Scripts – wesentlich effizienter,
     Abhängigkeiten *aus dem *Quelltext heraus* *schrittweise* clientseitig
     statt gesammelt serverseitig aufzulösen, im Unterschied zu dem, wie das
     mein Resource Builder derzeit halbdynamisch macht (die Abhängigkeiten
     müssen manuell gepflegt werden, was DRY widerspricht) und es diverse
     Bibliotheken statisch machen (was zu unnötigen Redundanzen in Caches
     führt).]

> Womit ich wieder zu meiner Frage komme, wie ich diese auflösen kann?
> Oder anders gefragt: woher weiss ich, welche Abhängigkeiten meine lokale
> Biliothek noch hat?

RTFM, UTSL.

Vorher aber musst Du das Problem korrekt analysieren.  „funktioniert NICHT“ 
ist unzureichend.  Siehe auch <http://glasgoogle.de/>.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

Back to de.comp.lang.javascript | Previous | Next — Previous in thread | Find similar

Thread

datepicker mit lokaler Version Jan Novak <repcom@gmail.com> - 2017-04-07 11:47 +0200
  Re: datepicker mit lokaler Version Jan Novak <repcom@gmail.com> - 2017-04-07 11:50 +0200
    Re: datepicker mit lokaler Version Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-04-07 22:37 +0200
  Re: datepicker mit lokaler Version Gerome Muent <kontakt@bmservices.de> - 2017-04-10 07:44 +0200
    Re: datepicker mit lokaler Version Jan Novak <repcom@gmail.com> - 2017-04-10 12:57 +0200
    Re: datepicker mit lokaler Version Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-04-10 20:52 +0200
      Re: datepicker mit lokaler Version Jan Novak <repcom@gmail.com> - 2017-04-11 15:13 +0200
        Re: datepicker mit lokaler Version Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-04-11 16:35 +0200

csiph-web