„Ihre Bibliothek kann wie Ihr Kind in eine für Sie unerwartete Richtung gehen“: Interview mit dem Ersteller von MobX



    Wie leben die Ersteller populärer Open Source-Bibliotheken? Es ist natürlich schön, wenn das Ergebnis Ihrer Arbeit vielen Menschen auf der ganzen Welt hilft. Werden Sie nicht mit Aufgaben überfordert, die nicht einmal Ihre Hauptaufgabe sind? Wie gehe ich damit um? Wie mutig können Sie Autorität delegieren?

    Michel Weststrata ist sich dessen alles bewusst: Seine MobX- Bibliothek hat mehr als 17.000 Sterne auf der Githaba, die Anzahl seiner Mitwirkenden hat längst mehr als hundert erreicht. Michelle wird in Kürze in Russland kommt am HolyJS auszuführen, so dass die Jungs aus dem Programmkomitee der Konferenz (Dmitry DmitryMakhnev Makhnev und Eugene bunopus cat) Detail fragten ihn, und über Open Source im Allgemeinen und speziell über MobX und Konferenzen.

    Evgeniy: Kannst du für diejenigen, die dich nicht kennen, ein wenig über dich sprechen?

    - Ja natürlich. Mein Name ist Michelle Weststrate (was für die meisten Leute zu schwer zu sagen ist), ich komme aus Holland. Meistens bin ich bekannt für meine Arbeit an MobX oder immer . Ich arbeite für Mendix. Wir machen Software, die Software herstellt: eine Anwendungsentwicklungsplattform, die von vielen Beratungsunternehmen verwendet wird. Wir automatisieren eine Vielzahl von Bankversicherungen und ähnlichen Systemen. Ich mache die technische Seite - das gefällt mir. Vor ungefähr zwei Jahren habe ich mich in die Welt von Open Source eingebunden. Von diesem Moment an war ich aktiv und speziell in der React-Community und allgemein in der JS-Community.

    Eugene: Was genau machst du in Mendix, bist du da technid?

    - ja Ich habe dort verschiedene Rollen, und die wichtigste ist technisch. Im Wesentlichen bedeutet dies, dass ich für die Auswahl der technischen Lösungen eines unserer „Stämme“ verantwortlich bin . Daher arbeite ich an einem Produkt, das eine Umgebung für mobile Anwendungen darstellt. Wir arbeiten mit vier Teams daran und im Grunde bin ich an der Entwicklung der richtigen architektonischen und technologischen Lösungen beteiligt. Außerdem programmiere ich immer noch. Dies ist ein Teil meiner Arbeit.

    Und das andere ist die Teilnahme an der Open Source Community. Dies ist eine "bilaterale" Aktivität. Zum einen machen wir coole technische Dinge, die ich auf Konferenzen teilen möchte, und ich spreche selbst oder ermutige Kollegen, zu sprechen. Andererseits ist die häufige Teilnahme an Konferenzen gut und im Gegenteil: Sie entdecken etwas, das für uns nützlich sein kann, dann studieren wir es und nehmen es in unseren Stack auf.

    Eugene: OSS bezieht sich in Ihrer Twitter-Beschreibung auf Evangelisation. Was ist das und warum ist es Ihnen wichtig?

    - Der erste Grund, warum dies wichtig ist: Ich habe festgestellt, dass wenn Sie Ihre Entwicklung in Open Source umsetzen, Sie zwar keine Zeit sparen, dass Sie jedoch beim Testen viel helfen und die Qualität verbessern. Weil eine Bibliothek wie MobX unter völlig anderen Bedingungen verwendet wird. Ich denke, dass Open Source in diesem Sinne einen Vorteil bietet, der auf andere Weise nur sehr schwer zu erreichen ist.

    Und die zweite: Ich glaube, dass unsere Entwicklungen auf „niedrigem Niveau“ kein Unternehmen definieren, also warum nicht teilen. Ich meine, das Unternehmen macht ein Produkt mehr oder weniger wettbewerbsfähig, das auf der Grundlage seiner Technologien hergestellt wird - und nicht diese Technologien an sich. Und alle profitieren von der Zusammenarbeit, sie lassen die Entwicklung insgesamt beschleunigen.

    Evgeniy: Manchmal sagen sie, dass eine "moneyless" Open Source tatsächlich ein sehr teures Vergnügen ist. Projekte wie Linux erfordern viel Geld von den Größen der Größenordnung von Oracle und Microsoft. Ist das so? Kann eine Open-Source-Community ohne große Anbieter und Geld existieren?

    - Ich denke, das hängt von der spezifischen Situation ab. Es gibt kleine Bibliotheken, die so existieren könnten. Projekte wie der erwähnte Linux-Kernel oder React Native sind jedoch so komplex und so viele Menschen sind von ihnen abhängig, dass sie ein verlässliches Finanzmodell benötigen. In diesem Fall wäre es ohne große Sponsoren sehr schwierig. Aber ich denke nicht, dass dies ein Problem ist. Ich denke, es ist wichtiger, dass Unternehmen lernen, Verantwortung zu übernehmen, als wenn wir ohne sie auskommen.

    Eugene: Zum Beispiel, wenn Facebook zu Ihnen kommt und sagt: "Lassen Sie uns MobX kaufen oder werden wir die Entwicklung unterstützen, um unter unserer Marke zu gehen"?

    - Nun, eigentlich sponsern sie schon! Sogar Spaß, aber Facebook ist einer der MobX-Sponsoren beim Open Collective . In gewissem Sinne ist dies bereits geschehen. Meiner Meinung nach ist das Open Collective ein gutes Beispiel dafür, wie wir die finanzielle Situation von Open Source verbessern können. Es ermöglicht Unternehmen, die Entwicklung des geeigneten Weges zu fördern, da es einen finanziell ernsthaften Ansatz gibt, mit Rechnungen und dergleichen.

    In Mendix werde ich tatsächlich für die Arbeit an MobX bezahlt, also bin ich nicht daran interessiert, ganz auf Facebook umzusteigen. Ich verstehe, dass es für andere interessant sein kann, aber ich sehe kein Problem damit. Wenn die Lizenz weiterhin Open Source bleibt, gibt es meiner Meinung nach nichts zu befürchten, dass das Produkt unter dem Markennamen des Hauptsponsors veröffentlicht wird. Es ist wie beim Fußball gucken im Fernsehen: Wenn jeder das Spiel sehen kann, gibt es keinen großen Unterschied, nämlich das Logo auf den T-Shirts.

    Yevgeny: Wenn eine große Firma eine Bibliothek sponsert, kann sie dann nicht sagen: "Da wir so viel bezahlen, lassen Sie uns das bitte tun"?

    - Kommen Sie zumindest nicht darauf, so dass es zu einem Problem wird. Wenn ich mich nicht irre, kann man im Webpack ein solches Modell verwenden, um dort Features zu bezahlen. Es besteht also ein gewisses Risiko, aber ich denke, dass die Verantwortlichen hier dafür verantwortlich sind, dass das Projekt seiner Philosophie treu bleibt. Innerhalb dieser Philosophie besteht jedoch wahrscheinlich viel Spielraum. Und außerdem, wenn im Open Source plötzlich etwas völlig schief geht, gibt es zumindest die Möglichkeit einer Gabelung.

    Eugene: Die Entwicklung von Open-Source-Software ist wie eine Kurve: Zuerst erstellen Sie eine Bibliothek, die niemand sonst benötigt, dann beginnen die Leute, sie zu benutzen, dann bekommen sie auf einer Githaba Tausende von Sternen und so weiter. Wenn ein Open Source-Projekt populär wird, kann dies sehr lange dauern. Wie viel geben Sie für MobX aus?

    - In letzter Zeit nicht sehr viel. MobX ist jetzt ziemlich stabil. In der Vergangenheit habe ich natürlich viel verbracht. Es war ganz anders. Ich denke, in den ersten Jahren waren es ein paar Abende in der Woche und viele weitere kleine Momente, in denen Sie nur ein kleineres Problem oder Fragen auf Twitter beantworten. Diese kleinen Dinge werden nicht als bedeutende Zeitinvestition empfunden, aber ich denke, dass sie insgesamt einen spürbaren Beitrag leisten. Es ist jedoch sehr schwer zu messen. Es ist wie das Überprüfen von Arbeitspost - Sie prüfen das Problem und senden die Antwort schnell.

    Evgeniy: Wie kann man in einer Situation produktiv sein, in der man Entwickler ist, eine Bibliothek erstellt hat, diese populär wurde und immer mehr Zeit benötigt? Sie haben Glück, Sie haben die Möglichkeit, dies während der Arbeitszeit zu tun. Aber wenn Sie bereits einen Job und ein Hobby haben und das Projekt populärer wird?

    - Nun, als ich anfing, an MobX zu arbeiten, war es auch nur in meiner Freizeit, die Arbeit wurde hinzugefügt, als das Projekt populär wurde. Aber ich habe ein paar tipps. Ich habe bemerkt, dass es ein paar Regeln gibt, die mir geholfen haben.

    Erstens: Überwachen Sie die Relevanz der Dokumentation. Wenn Sie dieselbe Frage drei- oder viermal erhalten haben, notieren Sie die Antwort unbedingt in der Dokumentation. Weil es Ihnen letztendlich Zeit spart.

    Zweitens: Seien Sie sehr wählerisch bei dem Thema, das Sie annehmen. Sobald Sie über den Fehler informiert werden, versuchen Sie, das Problem anhand der Beschreibung zu reproduzieren. In manchen Fällen stellen Sie fest, dass dies unmöglich ist und die Zeit bereits aufgewendet wurde. So fordere ich nun von der Ausgabe etwas, das ich direkt ausführen kann, ob es sich um den Code in der Sandbox oder um einen Pull-Request mit Unit-Tests handelt. Etwas, mit dem ich feststellen kann, wo das Problem in der Bibliothek oder auf der Benutzerseite liegt. Dies ist sehr wichtig, da ich dadurch Zeit sparen und sicherstellen kann, dass der Autor der Ausgabe bereit ist, seine Zeit zu investieren. Einige Leute sagen: "Ich habe keine Zeit, mir beim Spielen des Fehlers zu helfen", und das Gefühl kommt zum Vorschein: "Nun, dann habe ich keine Zeit, um Ihr Problem zu lösen." Schließlich wird eine Person wahrscheinlich für den Job bezahlt in der er meine Bibliothek benutzt - warum sollte ich dann meine Freizeit in sein Problem investieren? Im Allgemeinen hilft eine solche Selektivität, obwohl Sie sich dadurch etwas weniger verantwortlich fühlen, weil Sie allen im Allgemeinen helfen möchten. Aber ich fand, dass "jedem zu helfen" einfach unrealistisch ist.

    Und da ich an mehreren Bibliotheken arbeite, beantworte ich nicht alle Fragen sofort, sondern „springe“ von einer Bibliothek zur anderen: Ich arbeite abwechselnd für einige Tage und gehe dann zur nächsten über. Ich kann Ihnen in wenigen Minuten antworten, wenn Sie über das geschrieben haben, was Sie jetzt tun, aber ich kann nicht innerhalb von Tagen antworten, wenn Ihre Runde noch nicht erreicht ist. Es hilft mir, den Kontext seltener zu wechseln.

    Alle diese Tipps helfen, wenn Ihre Bibliothek an Popularität gewinnt.

    Evgeniy: Wenn der Ersteller einer beliebten Bibliothek antwortet: "Ich kann nicht reproduzieren, einen Komponententest schreiben", haben die Leute nicht das Gefühl, "er ist arrogant und möchte nicht helfen"?

    - Ich bin auf diesen Effekt gestoßen, aber sehr selten. Ich denke, der Benutzer versteht normalerweise, dass die Betreuer ziemlich beschäftigt sind und dass das Problem mit einer hohen Wahrscheinlichkeit auf seiner Seite liegt. Ich denke, wenn Sie den Lodash-Filter verwenden und Sie ein Problem haben, besteht unwillkürlich das Gefühl, dass "wahrscheinlich etwas falsch ist, weil Lodash von allen verwendet wird". Die meisten Menschen verstehen also, dass sie bei Fragen vorsichtig sein müssen.

    Evgeny: Wenn eine Bibliothek populär wird und mehr Zeit in Anspruch nimmt, wie viel kostet es, Ihre Rolle als Mitwirkender zu teilen und anderen Community-Mitgliedern Rechte zu geben?

    - Dies ist eine großartige Idee, ich gebe normalerweise die Rechte des Vertriebshändlers, sobald ich von einer Person mehrere gute Pull-Requests (oder sogar einen Pull-Request, wenn er groß ist) sehe. Meiner Meinung nach funktioniert es großartig. Im MobX-State-Tree wird zum Beispiel der Hauptteil der Arbeit jetzt von anderen Leuten erledigt, nicht von mir. Und es gibt andere Teile der Codebasis, die die Leute besser verstehen als ich, und es ist großartig, dass alles zu einem solchen Zustand gekommen ist. Für den "main" MobX ist dies nicht erforderlich, da dort bereits alles festgelegt ist. Die Algorithmen haben sich in den letzten Jahren nicht geändert, so dass die Supportarbeit gering ist. Aber im Fall des MobX-State-Tree habe ich bewusst solche Leute ausgewählt, die viele Benutzerbibliotheken erstellen, und ihnen die Rechte des Betreuers geben. Wenn Sie die Bibliothek in Ihrer täglichen Arbeit aktiv nutzen, stoßen Sie auf Muster oder häufige Probleme. was ich vermisst habe. Und ich denke, das gibt den Entwicklern Motivation und ein Gefühl der Zuverlässigkeit - schließlich können sie der Bibliothek helfen, mit dem zu arbeiten, auf das sie stoßen.

    Evgeny: Es gibt kein Gefühl, dass die Bibliothek wie ein Kind die Hände weg schlägt? Vielleicht sind Sie sich nicht einig, wie genau andere Leute es entwickeln?

    - Manchmal passiert es ein bisschen. Aber ich denke das ist normal. Sie hatten eine ausgezeichnete Analogie mit den Kindern: Mit der Zeit werden sie erwachsen, sie werden 18 Jahre alt, und dann müssen Sie sie gehen lassen, denn es ist Zeit, dass sie ihren eigenen Weg finden. Ich denke bis zu einem gewissen Grad auch mit Open Source-Bibliotheken. Wenn sie erfolgreich sind, werden Sie mit schwierigeren Situationen konfrontiert. Sie fangen an, sich mit Fällen zu befassen, mit denen Sie sich nicht befassen möchten. Der Code ist nicht mehr der schöne, saubere und minimale Code, den Sie ursprünglich wollten. Es ist unvermeidlich.

    MobX hat ein gutes Beispiel dafür: Ich habe ursprünglich für TypeScript geschrieben, wo Dekorateure sehr einfach sind, und dann wurde mit Babel begonnen, wo es eine völlig andere Implementierung gibt. Daher sind einige Teile der Codebasis sehr unansehnlich, da sie feststellen, ob Sie TypeScript oder Babel verwenden. Es hört sich schrecklich an und sieht schrecklich aus. Dies ist jedoch Teil des Jobs. Es ist nicht notwendig, es zu lieben, aber stellen Sie sicher, dass alles gut funktioniert. In diesem Sinne kann Ihr Kind in eine Richtung gehen, die Sie nicht beabsichtigt haben, aber das ist normal, denn letztendlich ist es wichtig, dass die Leute das Projekt erfolgreich nutzen können.

    Evgeny: Die Entwicklung verändert sich, vieles wird leichter als vor 10-20 Jahren. Was denken Sie im Zusammenhang mit diesen Veränderungen über die aktuelle Situation in der Open Source und was erwarten Sie von der Zukunft? Laufen große Unternehmen alles oder umgekehrt Enthusiasten?

    - Schwere Frage. Nicht sicher, dass es eine große Veränderung geben wird. Und es gibt gleichzeitig Änderungen in beiden Richtungen. Ich bin besonders beeindruckt von Facebook und Microsoft - wie sehr sie jetzt Open Source sind und inwieweit Drittentwickler dazu beitragen können. React Native ist ein besonders anschauliches Beispiel, bei dem ein Großteil der Arbeit nicht von Facebook stammt. Andererseits ist es für einen Einzelgänger wahrscheinlich nie einfacher, an einem Open-Source-Projekt teilzunehmen oder ein eigenes Projekt zu erstellen, wie es jetzt der Fall ist. Werkzeuge werden immer standardisierter, wir haben großartige Online-IDEsCodeSandbox und Gitpod . Ich habe in den letzten Wochen mit Gitpod gearbeitet, und das ist großartig: Ich kann Pull-Anfragen prüfen, ohne irgendetwas vor Ort zu tun. Sie können es einfach in Docker in einem Browser starten und dort entwickeln. Also weiß ich nicht, was die Änderungen sein werden.

    Eugene: Vor acht Jahren, als ich C ++ - Entwickler war, gab es keine solche Open Source-Community, wie sie jetzt ist. Und jetzt sehe ich in der Welt des Web und Javascript, dass sich Open Source immer schneller weiterentwickelt. Wird dieses Wachstum weitergehen?

    - Ich denke, die Bewegung wird sich fortsetzen. Einer der Gründe ist meiner Meinung nach der folgende: Sowohl Unternehmen als auch Entwickler verstehen immer besser, dass Open-Sourcing nicht nur für diejenigen nützlich ist, die es entwickeln oder nutzen, sondern auch dabei hilft, Mitarbeiter zu finden. Betrachtet man die Teilnahme einer Person an der Open Source, kann man mehr über sie verstehen, als wenn man sie den ganzen Tag interviewt. Die Art und Weise, wie er auf ein Problem reagiert oder sie in Gang setzt, zeigt viel. Ich denke, Entwickler und Unternehmen werden sich dieser Bedeutung zunehmend bewusst.

    Yevgeny: Sie glauben also, dass die Entwicklung einer Open-Source-Bibliothek beim Interview helfen kann?

    - genau. Wenn Sie ein Unternehmen sind und über solche Bibliotheken verfügen, die nicht eng mit Ihrer API verbunden sind, ist dies großartig, denn die Leute kommen zur Teilnahme - und es kann sich herausstellen, dass sie genau die sind, die Sie brauchen. Wenn Sie einen Ihrer Mitarbeiter einstellen, wird es für ihn einfacher, sich zusammenzuschließen, und Sie werden besser verstehen, was Sie erwarten. Ich denke, schon aus diesem Grund wurden viele interessante Dinge entdeckt.

    Dmitry: Wir haben über Open Source insgesamt gesprochen. Lassen Sie uns speziell auf MobX eingehen. Wie und warum hast du anfänglich damit angefangen?

    - Gute Frage. Wir in Mendix haben schon lange eine Windows-Anwendung in C # geschrieben. Vor ein paar Jahren haben wir uns entschieden, es ins Web zu portieren und herauszufinden, welchen Stack wir verwenden sollten. Die Reaktion hatte gerade erst begonnen, Angular existierte schon eine Weile, Ember war ziemlich beliebt. Und recht schnell verliebten wir uns in React wegen seines Komponentenmodells und der von ihm angebotenen Abstraktionsebene.

    Aber dann entdeckten wir, dass wir ein Leistungsproblem hatten. Es stellte sich heraus, dass es ziemlich teuer war, das DOM vollständig zu aktualisieren, selbst im Fall von React. In C # haben wir das Modell ständig aktualisiert und die gesamte Leinwand neu gezeichnet, und niemand hat irgendetwas optimiert, da alles sehr schnell lief und es deshalb nicht notwendig war, das Rendering rational anzugehen. Aber hier haben wir festgestellt, dass Sie im Fall des DOM nicht alles 60-mal pro Sekunde neu zeichnen können. Also haben wir überlegt, wie wir das effektiv machen können. Wir haben über den unveränderlichen Ansatz nachgedacht, der in unserem Fall aus mehreren Gründen nicht geeignet war. Eine davon ist, wie wir mit welchen Daten gearbeitet haben und wie sie gerendert wurden. Gleiche Information an verschiedenen Orten. Unsere Daten sind sehr schwer zu normalisieren. Und zweitens schien es, dass es immer noch zu viele Details geben musste.

    Aber was ist, wenn Sie den gleichen einfachen Code wie unser C # -Code schreiben, etwas "rendern" möchten und sich nicht darum kümmern möchten, wie es sich in der Zukunft ändern wird? Wenn Sie nicht zu den Komponenten sagen wollen: "Nehmen Sie diesen Teil der Daten von hier und diesen Teil von dort und dann können Sie etwas rendern"? Wir begannen zu erforschen, welche Technologien derzeit verfügbar sind, und kamen schnell zu dem Paradigma, das in Knockout, Meteor und (zumindest konzeptuell) sogar in Angular verwendet wird. Wo legen Sie weder die Beziehung zwischen Datenabhängigkeiten und Komponenten fest noch was gerendert werden soll.

    Ich begann zu verstehen, warum Menschen diese Ansätze oft hassen, besonders wenn die Anwendung wächst. Und es stellte sich heraus, dass die meisten Leute besorgt sind über mangelnde Vorhersagbarkeit und das "Debugging", dass etwas zu oft oder zu selten oder nicht in dieser Reihenfolge ausgeführt werden kann. Und ich habe beschlossen, dass wir besser umgehen können. Wir können dasselbe Ziel verfolgen, aber die Umsetzung intelligenter angehen. Und so erschien MobX. Es erfasst nicht nur die Beziehung zwischen Beobachtungen und Observablen, sondern erstellt einen ganzen Abhängigkeitsgraphen, sodass Sie sicher sein können, dass alle Beobachter auf die effizienteste Weise ausgeführt werden. Bei der reaktiven Programmierung gibt es das Konzept der "Panne" - hier kann es also nicht entstehen. In der Regel wurde bereits vorhanden, jedoch mit dem Versuch, es vorhersehbarer zu machen.

    Dmitry: Wenn ich also eine Art von Ansatz mag, aber die vorhandenen Bibliotheken nicht gut genug sind, können Sie es einfach besser machen und besser machen, und das kann populär werden?

    - Ja genau! Also habe ich es ursprünglich für unsere internen Zwecke geschrieben und bin dann zu ReactEurope gegangen. Es scheint, dass es 2015 war, und es wurde viel über Flux-Muster gesprochen. Dann tobten die Flux Wars. Und ich habe das Gefühl, dass die Leute viel Energie in das Problem investieren, das wir bereits gelöst haben. Und dann dachte ich, "es ist notwendig, das Konto zu eröffnen". Und es hat funktioniert. Vermutlich, weil es nicht "eine andere Implementierung von Flux" war, sondern etwas völlig anderes. Es war für viele Menschen hilfreich.

    Eugene: Die ursprüngliche MobX-Idee war einfach und jetzt gibt es eine Menge Code und Funktionen. Ist das Gefühl, dass alles zu kompliziert ist?

    - Da ist es! Ich habe immer das Gefühl "Ich möchte MobX Lite machen". In der Tat können Sie ein Analog von MobX erstellen, indem Sie 200 Codezeilen gepackt haben. Ich habe sogar einen Bericht, wo ich das gerne mache. Dort werden die wichtigsten reaktiven Algorithmen implementiert. Dann können Sie einige hundert Zeilen hinzufügen, um alles zu optimieren und das Projekt unter verschiedenen Bedingungen zu beschleunigen. Es stellt sich also der gesamte Kern von MobX heraus. Ich denke jedoch, dass drei Viertel des Codes bereits Dinge auf API-Ebene sind, wie etwa die Implementierung von Dekorateuren. Es gibt eine Grundidee, und es gibt alles, was die API so gut wie möglich macht. Zum Beispiel hat sich in MobX 5 im Vergleich zu MobX 4 das, was mit Proxy verbunden ist, geändert .

    Dmitry: Zum Thema Proxy. Bisher werden sie von den meisten Entwicklern nur in einigen Entwicklungswerkzeugen verwendet, und Sie haben sie bereits in der Produktion. Nicht ohne Nuancen?

    - Manchmal ist es nicht einfach, eines der ersten Projekte zu sein, in denen sie verwendet werden, aber Proxy ist vor langer Zeit erschienen, die stabile Implementierung vor etwa vier Jahren. Und noch vor einem Jahr wurden sie in allen Browsern implementiert. Die grundlegende Implementierung wurde in Chrome 8 veröffentlicht. Früher bedeutete ihre Verwendung jedoch einen erheblichen Overhead. Jetzt hat sie sich geändert.

    Eugene: Lass uns über den Staat sprechen. Wir erinnern uns an die Zeiten, als jQuery der König der Webentwicklung war, und dann gab es keine Gespräche über den Zustand des Clients, wir haben ihn in einem globalen Objekt gespeichert oder so. Erstellen Sie jetzt keine Anwendung, ohne den Status der Bibliothek wie Redux oder MobX zu steuern. Was hat sich geändert?

    - Ich denke, es gibt zwei Antworten. Zum einen hatten wir in jQuery-Anwendungen in der Regel keinen großen Status auf dem Client. Ich meine, jQuery wurde oft verwendet, um Interaktivität hinzuzufügen, wenn alles auf dem Server gespeichert war. Nun ist dies aufgrund der Verbreitung von Mikrodienstleistungen keine gute Praxis. Der wichtigere Grund für den Übergang von jQuery zu einem komponentenbasierten Modell wie React besteht darin, dass Sie an eigenständige, unabhängige Komponenten denken können, die sich besser zur Erhöhung der Codebasis eignen. Dadurch konnten wir die Erstellung komplexer Anwendungen vereinfachen. In unserem Fall verwenden wir beispielsweise die gleichen Statusdefinitionen im Frontend und Backend.
    Und ich denke, das staatliche Management hat für den Staat getan, was React für die Benutzeroberfläche getan hat. Zustandsverwaltung ermöglicht es Ihnen, Ihre Zustände in zusammenhängende Muster zu unterteilen. Sie können in sich abgeschlossene Datensätze und Logik verwenden, um sie ohne Benutzeroberfläche zu testen und besser zu kontrollieren.

    Eugene: Was denkst du über das zukünftige Management des Staates? Wir haben bereits den Punkt erreicht, an dem nichts mehr hinzuzufügen ist?

    - Ich glaube, wir haben es noch nicht erreicht. Besonders wenn es um Staatsführung geht, die auf unveränderliche Werte fokussiert. Ich denke, einer der Gründe, warum immer in diesem Jahr so ​​populär geworden ist, ist, dass die Aktualisierung der unveränderlichen Staaten für JS nativer wurde. Ich denke jedoch, dass in der Staatsverwaltung noch viel mehr getan werden kann. Um beispielsweise Informationen zu teilen, verwenden die meisten Personen Selektoren oderLinsen , aber es scheint mir, dass dies nicht sehr bequem ist. Ich denke, dass es immer mehr Ansätze gibt, zum Beispiel ist GraphQL sehr interessant zu erwähnen, obwohl es nicht sehr praktisch ist, wenn Sie mit lokalen Zuständen arbeiten müssen. Wir haben also noch Platz zum Wachsen ...

    Eugene: Können Sie ein oder zwei Features nennen, die Sie zu MobX hinzufügen möchten?

    - Es gibt eine Sache, die ich gerne machen würde, aber ich fürchte, dass es von allen weit entfernt sein wird. Ich möchte die Datenkonvertierung reaktiver gestalten. Ich meine das so: Stellen Sie sich vor, Sie haben eine einfache Aufgabenliste und wenden eine Filterung darauf an. Ihr Filter sollte beispielsweise alle noch nicht abgeschlossenen Aufgaben anzeigen. Das Problem ist, dass, wenn sich etwas geändert hat, der Filter alle ToDo-Elemente in der Liste durchläuft, während Sie nur die geänderten Elemente bearbeiten können. Und jetzt gibt es keine bequeme Möglichkeit, dies auszudrücken. Grundsätzlich kann die Datenkonvertierung jedoch reaktiver gestaltet werden als jetzt.

    Dmitry: Autoren von Volksbibliotheken sind eingeladen, auf der Konferenz zu sprechen und Schulungen durchzuführen. Ich möchte nach den Trainings fragen. In Russland mögen sie es nicht, etwas für Anfänger zu berücksichtigen. Was ist Ihre Einstellung und was begegnen Sie in Europa?

    - Ich mag Schulungen wirklich sehr und finde es eine gute Möglichkeit zu lernen. Ich persönlich lerne gerne auf zwei Arten: Entweder ich setze mich hin und lese ein Buch von vorne bis hinten oder ich komme zum Training. Videos sind nichts für mich, sie sind für immer entweder zu langsam oder zu schnell. Obwohl ich selbst mehrere Videokurse erstellt habe, hat es mir nicht gefallen. Als ich mich an Docker gewöhnte, ging ich zum Training. Und da dies eine sehr praktische Lektion ist, spüren Sie sofort, wie alles funktioniert, wie es im Allgemeinen ist und wie Sie es anwenden können. Training ist für mich nicht "für Jugendliche". Meiner Meinung nach ist das wichtigste daran, dass dies der schnellste Weg ist, eine neue Technologie zu beherrschen, mit der Sie nicht besonders vertraut waren. Ich denke, das ist der Hauptwert, und Sie werden dies nicht aus einem Buch erhalten. In einem Buch geht es eher um ein allgemeines Bild, anhand dessen Sie verstehen können, wie relevant etwas für Sie überhaupt ist. Wenn Sie jedoch wirklich mit etwas arbeiten möchten oder ernsthaft über diese Option nachdenken, wird das Training am schnellsten sein. In den Pausen stellen sich die Menschen spezifische Fragen zu den spezifischen Schwierigkeiten, mit denen sie konfrontiert sind, oder fragen nach der Anwendung des Erlernten in ihrer jeweiligen Situation. Dies ist ein Vorteil von Schulungen: Sie können mit jemandem sprechen und Fragen stellen, die sich direkt auf Ihre Situation beziehen. Ich glaube wirklich an diese Art, neue Technologien zu beherrschen.

    Eugene: Außerdem glauben viele (zumindest in Russland), dass Sie nicht zu Konferenzen gehen sollten, da Sie Texte auf Medium lesen oder Videos auf YouTube ansehen können. Was denken Sie?

    - Ich denke, im Gegensatz zum Training ist das Hauptziel der Konferenz nicht das Training. Auf jeden Fall ist meine persönliche Meinung. Der Hauptgrund für die Konferenz ist, inspiriert zu werden. Was passiert in der Branche, was machen die Leute ... Sie wollen lernen. Vernetzung kommt mit. Wenn Sie mit Kollegen zu einer Konferenz kommen, versuchen Sie, nicht zu viel mit ihnen zu sprechen. Du kennst sie schon. Sie wissen, welche Probleme sie lösen. Viel interessanter ist es, mit zufälligen Leuten zu sprechen, die zum Beispiel in der Schlange stehen, um etwas zu essen. Sie können sehen, was sie tun, welche Probleme sie lösen und welche Erfahrungen sie mit der Bibliothek haben, über die jemand am Morgen einen Bericht abgegeben hat. Und suchen Sie nach Referenten, wenn Sie Fragen haben. Viele Leute haben Angst, sich den Rednern zu nähern, aber für mich als Redner (und, denke ich, Für die meisten anderen Redner ist das Gespräch mit dem Publikum ein interessanter Teil der Konferenz. Naja, bitte kontaktiere mich nicht fünf Minuten vor meinem Auftritt auf der Bühne, aber den Rest der Zeit versuche ich sehr zugänglich zu sein. Also zögern Sie nicht und kontaktieren Sie uns.

    Eugene: Großartiger Rat. Sie befinden sich zum ersten Mal in Russland - was erwarten Sie von Moskau und von der Konferenz?

    - Ich möchte unbedingt Moskau anschauen und bin definitiv schockiert. Und ich habe auch bemerkt, dass es in Russland viele MobX-Benutzer gibt. Ich sehe es auf dem Tracker, auf Commits. Daher hoffe ich, auf der Konferenz viele Benutzer von MobX kennenzulernen.

    Auf der HolyJS 2018 Moskau , die vom 24. bis 25. November stattfindet , können Sie Michel sehen und ihm Fragen stellen . Dort wird er mehr über das Staatsmanagement sprechen. Die Beschreibung der Konferenzberichte finden Sie auf der Website .

    Jetzt auch beliebt: