Jak budować niestandardowe elementy sieciowe do pracy z obiema specyfikacjami


9

Muszę zbudować komponent, który powinien działać z obiema specyfikacjami, custom elements spec v0które stały się przestarzałe i custom elements spec v1najnowszą stabilną wersją.

Jeśli skompiluję komponenty ze custom elements v0specyfikacją, niektóre aplikacje napotkają problemy, ponieważ używają polymer 2i powyżej, i ten sam problem z polymer 1aplikacjami, które nie będą działać ze custom elements v1specyfikacją.

Nie mam kontroli nad aplikacjami, aby zmieniać wielopełniacze , niektóre aplikacje muszą używać wieloskładników obsługujących stare specyfikacje, a niektóre używają nowych wieloskładników.

Szukam solidnego rozwiązania, które pozwoliłoby połączyć obie specyfikacje, aby uruchomić moje niestandardowe elementy we wszystkich aplikacjach, niezależnie od wersji wielopełniacza. Mogę dodać dowolny fragment polifillu lub fragmentu kodu do moich komponentów, aby mogły one działać w dowolnym miejscu, nie znalazłem żadnej takiej biblioteki lub polifillu, które obsługiwałyby obie specyfikacje w moich badaniach.

Planuję napisać adapter, który może łączyć obie specyfikacje, takie jak mapowanie wspomniane poniżej dla dołączonego wywołania zwrotnego, opinie na temat tej myśli będą bardzo mile widziane.

connectedCallback(){
    this.attachedCallback();
}

Próbowałem użyć stenciljs, ale może działać tylko z najnowszą wersją specyfikacji elementów niestandardowych. Nie znalazłem żadnego sposobu na ulepszenie go, aby działał z wcześniejszą specyfikacją.

Proszę zasugerować realne alternatywy i możliwe rozwiązania wyżej wymienionej sytuacji.

Odpowiedzi:


1

Zasadniczo twój komponent ma pewne zależności, które są zdefiniowane w polypełniaczach albo bezpośrednio, albo pośrednio. Jeśli weźmiemy pod uwagę te zależności jako węzły wykresu zależności, mamy problem z tym, że wykresy są różne. Możliwe jest, że węzeł istnieje na obu wykresach, ale zachowuje się inaczej (starsza i nowsza implementacja tego samego function), a także możliwe, że brakuje niektórych węzłów na wykresie w innym. Możesz oczywiście wprowadzić własne wypełnienia lub coś podobnego, ale wtedy będziesz musiał zachować wypełnienia, które mogą być mniej niż pomocne.

Lepszym rozwiązaniem moim zdaniem jest wdrożenie function, jak

function getWebComponentsVersion() {
    //Return v1 if it's v1 and v0 if it's v0
}

Nie jestem pewien, jak to zaimplementować function, ale jeśli istnieje taka, functionktóra daje odpowiednią wersję lub oczywiste różnice między funkcjami, możesz odpowiednio zaimplementować powyższą funkcję. Następnie uruchom ten kod:

if (getWebComponentsVersion() === "v1") {
    //code for v1
} else {
    //code for v0
}

dziękuję za twoją odpowiedź, w tym przypadku muszę zachować dwie wersje kodu komponentu, co byłoby uciążliwe podczas dodawania funkcji, aw dłuższej perspektywie problemy naprawcze stałyby się gorączkowym procesem.
Konga Raju,

@KongaRaju to rzeczywiście wada, ale jeśli uda się zawęzić obszar problemów specyficznych dla wersji i rozszerzyć obszar kodu, który można zastosować do obu wersji, problem ten może być mniej niepokojący, niż mogłoby się wydawać na pierwszy rzut oka.
Lajos Arpad

-1

Podejrzewam, że wiesz o tym Custom Elements v0 is deprecated at M70, and will be removed in M80, by February, 2020..

Możesz przejść do Can I usestrony internetowej i sprawdzić wersje obsługi przeglądarki, aby zobaczyć, która przeglądarka powinna załadować, która wersja elementów niestandardowych ...

Następnie zaimplementuj poniżej, aby sprawdzić przeglądarkę i wersję, i odpowiednio załaduj odpowiedni element niestandardowy dla żądanej przeglądarki ( więcej tutaj ), jeśli nie chcesz używać bibliotek zewnętrznych.

Jeśli nie masz nic przeciwko korzystaniu z bibliotek zewnętrznych, wypróbuj Bowser w celu wykrycia wersji, platformy itp.

navigator.browserSpecs = (function(){
    var ua = navigator.userAgent, tem, 
        M = ua.match(/(opera|chrome|safari|firefox|msie|trident(?=\/))\/?\s*(\d+)/i) || [];
    if(/trident/i.test(M[1])){
        tem = /\brv[ :]+(\d+)/g.exec(ua) || [];
        return {name:'IE',version:(tem[1] || '')};
    }
    if(M[1]=== 'Chrome'){
        tem = ua.match(/\b(OPR|Edge)\/(\d+)/);
        if(tem != null) return {name:tem[1].replace('OPR', 'Opera'),version:tem[2]};
    }
    M = M[2]? [M[1], M[2]]: [navigator.appName, navigator.appVersion, '-?'];
    if((tem = ua.match(/version\/(\d+)/i))!= null)
        M.splice(1, 1, tem[1]);
    return {name:M[0], version:M[1]};
})();

console.log(navigator.browserSpecs); //Object { name: "Firefox", version: "42" }

if (navigator.browserSpecs.name == 'Chrome') {
    // Do something for Chrome.
    if (navigator.browserSpecs.version > 76) {
        // Do something for Chrome versions greater than 76 like load v1.
    }
}
else {
    // Do something for all other browsers.
}


Przede wszystkim dziękuję za odpowiedź. Prawdziwy problem polega na zbudowaniu komponentu po wykryciu wersji przeglądarki? Dodatkowym krokiem byłoby dodanie czeku w celu wykrycia wersji przeglądarki.
Konga Raju,

Wygląda na to, że posunąłem się za daleko w założeniach - moim pomysłem powyżej było zbudowanie 2 osobnych komponentów i załadowanie ich w odpowiednich przeglądarkach.
Mac_W,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.