Slack a récemment rendu disponible la version 3.0 dans son canal bêta, avec de nombreuses améliorations de performances et corrections de bugs. À la base, la plupart des changements ont tourné autour de la migration du composant webView d'Electron vers browserView, une alternative plus récente et plus stable. Charlie Hess, ingénieur à Slack, a publié un blog décrivant ce périple.
Slack est basé sur Electron, un framework qui est utilisé pour développer des applications de bureau en utilisant des technologies web comme NodeJS et Chromium. Même si ce choix de technologie a permis à Slack de rester multi-plateforme, il n'a pas été aussi stable que l'équipe le souhaiterait. Hess explique qu'il s'agit principalement de webView, une fonctionnalité d'Electron utilisée pour le rendu de pages Web.
L'un des principaux problèmes avec webView était que le composant lui-même est implémenté directement dans Chromium. Cela signifie que les corrections de bugs finissent par devoir être effectuées par l'équipe Chrome, bloquant ainsi toute progression. Pour contourner ce problème, l'équipe d'Electron a présenté browserView, un composant qui se comporte davantage comme un onglet Chrome et fait partie de la hiérarchie des fenêtres du système d'exploitation. C'est cette partie qui représente le gros du travail pour Slack 3.0 :
Ce que nous entendons par là, est que - contrairement au WebView - vous ne pouvez pas déposer un BrowserView dans le DOM et le manipuler avec CSS. Comme les fenêtres de niveau supérieur, ces vues peuvent uniquement être créées à partir du processus Node d'arrière-plan. Notre application ayant été écrite comme un ensemble de composants React embarquant la webView, ces composants étaient dans le DOM, on s'orientait donc vers une réécriture complète.
Cependant, en faisant de bons choix technologiques et de bonnes décisions en matière de conception, Hess explique que la réécriture a été rendue aussi indolore que possible, et il estime qu'au final, ils ont pu conserver plus de 70% de leur code original.
Une décision prise par l'équipe était d'introduire redux-electron avec Redux. Essentiellement, Slack est composé de nombreux processus, chacun contenant son propre store Redux. Redux-electron utilise Electrons IPC (communication inter-processus) pour partager les actions entre les processus, utilisant le processus principal comme source unique de vérité et traitant les autres comme des proxies.
Un autre choix a été TypeScript, que Hess déclare comme quelque chose qui a apporté des avantages majeurs au projet. Dans le cas d'un refactoring majeur, le typage fort a permis d'éviter de nombreux bugs qui n'auraient pas été détectés autrement :
Pas besoin de réfléchir au retour d'un flatMap (est-ce que j'obtiens le tableau ou juste un élément ?), l'ordre des arguments pour un reduce, ou le nom de cet opérateur qui ressemble à throttle mais commence par un D ... (debounce). Lorsqu'il est associé à la saisie semi-automatique dans VS Code, l'écriture de JavaScript ressemble beaucoup à l'écriture, disons, C #. Et je dis cela dans le bon sens du terme.
Enfin, Hess explique que Slack utilise redux-observable, et RxJS à 5 middleware pour Redux. Il apporte essentiellement la programmation réactive à Redux via une primitive épique, une fonction qui prend et produit un flux d'actions.
Le blog complet est disponible en ligne, et va plus en détails avec des exemples de code. En outre, la dernière version de Slack peut être téléchargée sur la chaîne bêta.