小程序无缝滚动
The patient chart in One Medical’s Electronic Health Record system is our most feature-heavy in-house single page application. It is currently undergoing an upgrade from AngularJS to Angular, with a migration strategy that involves rewriting product features in angular and downgrading them to AngularJS at runtime. Throughout this transition, we aggressively tackled various flavors of tech debt including state management complexities, nested forms, routing and UX issues, etc. We also setup an internal component library and documented these reusable components in storybook. Somewhere in the mix of all these things, the related style debt did not receive much attention.
One Medical电子健康记录系统中的患者图表是我们功能最重的内部单页应用程序。 目前，它正在从AngularJS升级到Angular，其迁移策略涉及重写angular中的产品功能，并在运行时将其降级为AngularJS。 在整个过渡过程中，我们积极解决了各种技术债务问题，包括状态管理复杂性，嵌套表单，路由和UX问题等。我们还建立了内部组件库，并在故事书中记录了这些可重用组件。 在所有这些东西的某个地方，相关风格的债务并没有引起太多关注。
About half way through the migration, the design team requested a move to a standard grid system and a different font and scale which would support a greater design system endeavor. Naturally, such a challenge midway through an epic migration project seemed like just the right amount of fun to tackle. So began our journey into addressing style debt.
在迁移的一半左右，设计团队要求迁移到标准网格系统和不同的字体和比例，以支持更大的设计系统。 自然，在史诗般的迁移项目中途遇到的挑战似乎正好解决了很多有趣的事情。 因此，我们开始了解决风格债务的旅程。
技术挑战与机遇 (Technical Challenge & Opportunity)
The opportunity to address the style debt was an interesting but vague one. On the surface level, the SASS implementation in the code base seemed reasonable. There were SASS variables, extensions, helper mixins, etc. On the angular side of things, we had components that simplified parts of the application into smaller pieces and encapsulated the UI features. The effort for this project wasn’t an easy one to gauge, but an initial spike to dive into the css to learn more helped plan out the project.
解决风格债务的机会是一个有趣但模糊的机会。 从表面上看，代码库中的SASS实现似乎是合理的。 有SASS变量，扩展名，辅助混合器等。在事物的角度来看，我们有一些组件将应用程序的各个部分简化为较小的部分，并封装了UI功能。 这个项目的工作量很难衡量，但是要想进一步了解该项目，首先要深入研究CSS以了解更多信息。
Contrary to the recommended best practices of angular components, the style in the application was held together in a global css styling approach of pre-angular applications. Not only did this make the styles and DOM structure fragile, it was tough to change existing style and DOM structure without the commit size growing and the confidence level in the quality dropping. Part of the risk factor was also the lack of a full suite of e2e tests to cover all feature interactions in the system.
与推荐的角度组件最佳实践相反，该应用程序中的样式以预角度应用程序的全局CSS样式化方法结合在一起。 这不仅使样式和DOM结构变得脆弱，而且很难在不增加提交大小和降低质量的置信度的情况下更改现有样式和DOM结构。 风险因素之一还在于缺乏一套完整的e2e测试来涵盖系统中所有功能交互。
The style debt wasn’t as bad as a Pandora’s box but there were some 👻👻👻surprises along the way which would prevent future scaling of the application style into areas of responsive layout and font sizing. Some of these were:
样式的负担不如Pandora的包装盒那么糟糕，但是在此过程中存在一些👻👻👻意外，可能会阻止将来将应用程序样式缩放到响应式布局和字体大小的区域。 其中一些是：
- Massive amounts of nested height calculations 大量的嵌套高度计算
- Non-standard body font size非标准正文字体大小
- Global line heights to determine padding全局线高确定填充
- Mix of px, rem, percentage and rem calculated valuespx，rem，百分比和rem计算值的混合
- Global line heights to determine padding were some of the ones which would prevent future scaling of the application style into areas of responsive layout and font sizing.确定填充的全局行高是其中的一些，这会阻止将来将应用程序样式缩放到响应式布局和字体大小的区域。
Was it worth fixing some of these issues or all of them? How were we going to ship this code for alpha testers without breaking changes to others? The more difficult question was, how do we create reviewable PRs, ensure quality, and iteratively ship code that changes the layout and style plumbing of the application? While this style debt cleanup wasn’t part of the original request, it was an opportunity to address a bigger issue in the application.
修复其中一些或全部问题是否值得？ 我们如何在不破坏其他更改的情况下为Alpha测试人员提供此代码？ 更为棘手的问题是，我们如何创建可审查的PR，确保质量，并反复发布更改应用程序布局和样式管道的代码？ 尽管这种债务清算并不是最初请求的一部分，但这是一个解决应用程序中更大问题的机会。
How do we create reviewable PRs, ensure quality, and iteratively ship code that changes the layout and style plumbing of the application?
我们如何创建可审查的PR，确保质量，并反复发布更改应用程序布局和样式管道的代码？
选择的解决方案 (Chosen Solution)
One thing that has been clear in our migration efforts is that feature flagged delivery coupled with a period of alpha testing with users in production has resulted in smoother releases of complex features. We decided that shipping incremental changes behind features flags to achieve the font and grid system (henceforth interface) update was the way to go.
在我们的迁移工作中显而易见的一件事是，功能标记交付以及在生产中与用户进行一段时间的alpha测试使复杂功能的发布更加顺畅。 我们决定将功能标记后面的增量更改交付以实现字体和网格系统(此后为接口)更新是必须的。
One thing that has been clear in our migration efforts is that feature flagged delivery coupled with a period of alpha testing with users in production has resulted in smoother releases of complex features.
在我们的迁移工作中显而易见的一件事是，功能标记交付以及在生产中与用户进行一段时间的alpha测试使复杂功能的发布更加顺畅。
We started with the idea of themes to determine which interface would be visible. Cory Rylan’s article on Theming Angular apps with CSS Custom Properties was a great starting point. Using CSS variables instead of sass variables to hot swap themes was a requirement (for debugging and comparing themes) and a bonus for future customizability. We extended the service to maintain an RxJS BehaviorSubject and to subscribe to an NgRX store to relay the latest theme.
我们从主题的概念开始，以确定哪个界面可见。 Cory Rylan的文章“使用CSS自定义属性设置Angular应用的主题”是一个很好的起点。 使用CSS变量而不是sass变量来热插拔主题(调试和比较主题)是一项要求，并且对于将来的可自定义性是一项奖励。 我们扩展了服务，以维护RxJS BehaviorSubject并订阅NgRX存储以中继最新主题。
We built upon the theme strategy by using a custom directive to listen to the theme defined in the service and apply custom classes and properties to a DOM level element.
我们通过使用自定义指令来侦听服务中定义的主题并将自定义类和属性应用于DOM级别元素，从而基于主题策略。
This allowed us to use a combination of inherited styles as well as inject styles into components that used angular style encapsulation. Now we had a recipe to use to deliver incremental changes across the application!
这使我们能够使用继承样式的组合，以及将样式注入到使用角度样式封装的组件中。 现在，我们有了一个配方，可以在整个应用程序中交付增量更改！
TL; DR (TL;DR)
By using a combination of themes, directives, layout components, feature flags, and CSS variables, we were able to systematically apply theme-based rendering of components. This allowed us to deprecated the old styles into an older theme and use a new theme to define the newer styles. We additionally introduced layout components to reduce the cognitive overhead of large components that tackled a container component’s responsibility as well as DOM structure and style responsibility.
通过组合使用主题，指令，布局组件，功能标志和CSS变量，我们能够系统地应用基于主题的组件呈现。 这使我们可以将旧样式弃用为较旧的主题，并使用新主题来定义较新的样式。 我们还引入了布局组件，以减少处理容器组件职责以及DOM结构和样式职责的大型组件的认知开销。
代码样例 (Code Sample)
To showcase our solution, we’ve setup a stackblitz project that shows the theme service and directive working together to swap the interface.
为了展示我们的解决方案，我们设置了一个stackblitz项目，该项目显示主题服务和指令一起工作以交换接口。
未来状态(Future State)
The theme switching infrastructure put in place has allowed us to complete the Font and Grid Upgrade project. The old styles that we have deprecated can be deleted safely once we deprecate the theme in the angular code. The infrastructure has received good feedback so far and the design team has already inquired about experimenting with colors and accessibility projects using this solution! To be honest, the solution was for getting us to Dark Mode (which was the main goal all along 😎).
到位的主题转换基础结构使我们能够完成字体和网格升级项目。 一旦我们在角度代码中弃用了主题，就可以安全地删除我们已弃用的旧样式。 到目前为止，基础结构已经收到了很好的反馈，设计团队已经询问使用该解决方案尝试颜色和可访问性项目！ 老实说，解决方案是使我们进入黑暗模式(这一直是😎的主要目标)。
Special thanks to Josh De Gouveia in helping me bounce ideas off for this blog and for code pairing with me through the Font & Grid Upgrade project.
Thanks to my Angular migration team coworkers at One Medical, Pamela Ocampo & Timothy Kutnick, for keeping that bar high 🏋️♀️, and to our designer Brittany Staten for all design related support!
特别感谢Josh De Gouveia帮助我从这个博客中获得灵感，并通过Font＆Grid Upgrade项目与我进行了代码配对。 多亏我在One Medical的Angular迁移团队的同事Pamela Ocampo和Timothy Kutnick保持了较高的标准，并感谢我们的设计师Brittany Staten提供了所有与设计有关的支持！
小程序无缝滚动
1662
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
