Właśnie usunąłem setki linijek kodu, które napisałem wczoraj i zastąpiłem je 32 linijkami nowego kodu. Było to dla funkcji   , używanej do wskazywania, czy dźwięk jest odtwarzany. TheOpenPresenter  Co jakiś czas pracowałem nad funkcjonalnością, która wydaje się dość prosta do wdrożenia. W tym przypadku potrzebowałem tylko pokazać tę ikonę, gdy odtwarzany jest dźwięk.   Wystarczająco proste. Każdy z nich jest sceną zawierającą wiele wtyczek. Każda wtyczka ma swoją własną właściwość, taką jak   . Możemy scalić wartości między wtyczkami, a jeśli flaga jest prawdziwa, możemy wyświetlić ikonę. isPlaying  Projektowanie rozwiązania  Głównym problemem jest to, jak uzyskać dostęp do tych danych. Widzisz, moglibyśmy uzyskać dostęp do danych bezpośrednio. Ale każda wtyczka może mieć swój własny schemat. Podczas gdy niektóre wtyczki mogą mieć prostą właściwość   , niektóre inne mogą potrzebować czegoś bardziej skomplikowanego, aby reprezentować swój status odtwarzania. isPlaying  Proste, dlaczego nie pozwolić wtyczce zarejestrować wywołania zwrotnego/funkcji zwracającej stan?  To ten sam wzorzec, którego TheOpenPresenter używa w wielu swoich wtyczkach. A skoro już przy tym jesteśmy, możemy go wyabstrahować do obiektu   . Więc jeśli kiedykolwiek będziemy potrzebować innego stanu, możemy go tutaj dodać. Oto jak to może wyglądać dla wtyczki: SceneState   // The pattern we use for plugins serverPluginApi.onPluginDataCreated(pluginName, onPluginDataCreated); serverPluginApi.onPluginDataLoaded(pluginName, onPluginDataLoaded); serverPluginApi.registerRemoteViewWebComponent( pluginName, remoteWebComponentTag, ); // Example of how the new API might look like serverPluginApi.registerSceneState( pluginName, (_, rendererData) => { return { audioIsPlaying: !!rendererData.find((x) => x.isPlaying), } }, );  Obsługa serwera  Zauważ, że powyższy kod jest obsługiwany na serwerze. Dzieje się tak, ponieważ TheOpenPresenter składa się z 3 oddzielnych komponentów:  Pilot – gdzie wyświetla się ten sygnał dźwiękowy  Renderer - odtwarza dźwięk  Serwer - łączy dwa  Najlepiej byłoby, gdybyśmy zajęli się tym w frontendzie (zdalnie), aby nie dodawać dodatkowego obciążenia do serwera. Jednak rejestrowanie tej funkcji może być chaotyczne. Nasz frontend używa mikro-architektury frontendu załadowanej komponentami internetowymi.  Czerwony obszar poniżej to powłoka React. Zielony obszar jest ładowany przez komponenty sieciowe i jest zarządzany przez każdą wtyczkę.   Zauważ, że ikona audio znajduje się po lewej stronie powłoki. Jak dostarczyć funkcji, której potrzebujemy do powłoki? Możemy dołączyć funkcję JS do pakietu komponentów internetowych, ale na dłuższą metę brzmi to jak bałagan.  Wydaje się, że właściwym sposobem jest obsłużenie tego na serwerze.  Przepływ danych przez  Mając to ustalone, czas na wdrożenie. Jest kilka rzeczy do zrobienia:  Utwórz API wtyczki  Przekaż te dane do front-endu  Konsumuj i aktualizuj interfejs użytkownika  Realizowanie  Nie będę zanudzał Cię szczegółami, więc oto przegląd. API nie było całkiem proste, ponieważ nasze dane mogą być dość mylące. Krótko mówiąc: scena może mieć wiele wtyczek. I może być wiele rendererów, z których każdy wyświetla scenę w inny sposób. Więc wtyczka może mieć wiele rendererów pokazujących ją na różne sposoby. Ale z odrobiną manipulacji danymi problem został rozwiązany.   Konsumowanie i aktualizowanie interfejsu użytkownika  Konsumpcja wartości była prosta. Rozważałem użycie protokołu świadomości Yjs do dostarczenia danych, ponieważ są one w czasie rzeczywistym, a struktura jest już na miejscu. W ten sposób przechowywany jest stan. Jednak uwzględnienie tych danych z serwera stanowi osobny problem. Dlatego zdecydowałem się użyć GraphQL — protokołu, którego używamy do wszystkiego innego na platformie.  Więc wszystko, co musimy zrobić, to wywołać punkt końcowy, nasłuchiwać go za pomocą subskrypcji GraphQL i wyświetlić ikonę, jeśli to konieczne. Gotowe.   Dostarczanie tych danych do front-endu  Na szczęście używamy   , co sprawia, że rozszerzanie schematu GraphQL jest dość proste. Możemy również uczynić go subskrypcją, po prostu dodając   do schematu GraphQL. Następnie będzie on obserwować temat i aktualizować wartość za każdym razem, gdy wywołamy   w tym temacie. Na przykład: Postgraphile @pgSubscription pg_notify   await pgPool.query( `select pg_notify('graphql:sceneState:${id}','{}');`, [], );  Manipulowanie danymi było irytujące, ale wystarczyło trochę cierpliwości i gotowe!  Ostatnim elementem układanki jest wywołanie   , gdy zajdzie taka potrzeba. pg_notify  W tym celu możemy dodać obiekt nasłuchujący do stanu (Yjs) i wywołać powiadomienie za każdym razem, gdy coś się zmieni:   state.observeDeep(async () => { // Call pg_notify here });  Jedyne, co pozostało do zrobienia, to poprawa wydajności. Obecnie funkcja jest wywoływana przy każdej małej zmianie, jest również aktualizowana do frontendu. Możemy obliczyć stan wynikowy i porównać, czy coś się zmienia, zanim wprowadzimy aktualizację.  Lepsze rozwiązanie  To rozwiązanie z pewnością działa. Ale nienawidziłem tego, że słuchaliśmy każdej zmiany. To niepotrzebne i nie jestem pewien, jak skalowalna będzie wydajność. Czy istnieje lepsze rozwiązanie?  Więc na chwilę się zatrzymałem i przyszedł mi do głowy pomysł:  co by było, gdybyśmy wrócili do podstaw i wykorzystali dane z Yjs?  Problem polegał na tym, że każda wtyczka może używać różnych sposobów, aby wskazać stan odtwarzania. Dlatego potrzebowaliśmy sposobu, aby wiedzieć, jak obliczyć wynikowy stan samodzielnie. Ale zamiast pozwolić użytkownikowi przekazać funkcję,  dlaczego nie zarezerwować właściwości, której może użyć, aby to wskazać?  Zamiast przekazywać funkcję do obliczenia stanu, każda wtyczka mogłaby ustawić zarezerwowany stan bezpośrednio obok swoich istniejących danych za pomocą właściwości, takich jak   . Mogliby użyć tej wartości bezpośrednio lub mogliby ją zsynchronizować ze swoimi istniejącymi właściwościami, tak jak tutaj: __audioIsPlaying   const onRendererDataLoaded = ( rendererData, ) => { watchYjs( // Watch the isPlaying property (x) => x.isPlaying, () => { // And if it changes, sync the __audioIsPlaying property rendererData.set("__audioIsPlaying", rendererData.get("isPlaying")); }, ); };  Usuwanie starego kodu  Nowa metoda jest genialna. Bez dodatkowego słuchacza, bez dodatkowego API, tylko prosta zarezerwowana właściwość.  Koszt? Cóż, już napisałem 95% pierwszej implementacji 🫣     „Będzie tak szkoda to usunąć, skoro tak długo nad tym pracowałem. Wszystko inne jest idealne, poza tą jedną rzeczą!” – Mój umysł  To nie jest mój pierwszy raz. Ani drugi, ani trzeci. Tym razem to było tylko kilka godzin pracy. Im dłużej trwa implementacja, tym trudniej jest się od tego uwolnić. Ale jeśli nie powinniśmy przywiązywać się do serwerów, nie powinniśmy też przywiązywać się do kodu, który piszemy.  Oczywiste jest, że druga implementacja jest lepsza. Jest szybsza, ma mniej ruchomych części, mniej powierzchni API i mniej kodu do utrzymania.   dodała 289 nowych linii, podczas gdy   dodała tylko 32 nowe linie. Pierwsza implementacja druga implementacja   Jaką więc można z tego wyciągnąć lekcję?  Cóż, może najpierw znajdź najprostsze rozwiązanie. Ale czasami nie dochodzimy do najlepszego rozwiązania, po prostu o nim myśląc. Jeśli tak jest,   . I może napisz post na blogu, żeby coś z tego wyciągnąć! nie kochaj swojego kodu i nie bój się go wyrzucić  Jeśli dotarłeś aż tutaj, możesz spróbować   ! To system prezentacji typu open-source, który pozwala Ci zdalnie kontrolować dowolny ekran. TheOpenPresenter  Pokaż pokazy slajdów, odtwarzaj filmy, używaj jako pulpitów nawigacyjnych i wiele więcej. Oprogramowanie jest wciąż na bardzo wczesnym etapie rozwoju, jak widać z tego posta, ale jest wystarczająco stabilne, aby używać go regularnie. Osobiście używam go na moich spotkaniach co tydzień.  W razie pytań, pytaj. Lub zgłaszaj problemy w   . repozytorium Github

2022 - HackerNoon Contributor of the Year - Developer

Read My Stories

Nominated for 2022 - HackerNoon Contributor of the Year - Developer

Ten dźwięk jest produkowany w oryginalnym języku historii!

Zakochałem się w swoim kodzie, a potem musiałem go zabić

About Author

UWAGI

ZAWIEŚĆ TAGI

ARTYKUŁ TEN ZOSTAŁ PREZENTOWANY W

Related Stories

Understanding Metaverse: A Basic Explanation

Meet the Writer: HackerNoon's Contributor Emmanuel Nwaka, Content Marketing Professional

Meet the Writer: Hacker Noon's Contributor Elay Romanov of Daiger

Verified Writers

Understanding Metaverse: A Basic Explanation

Meet the Writer: HackerNoon's Contributor Emmanuel Nwaka, Content Marketing Professional

Meet the Writer: Hacker Noon's Contributor Elay Romanov of Daiger

Verified Writers

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps