Resources

Ripple Severity Scale

The Design System Team uses a number of factors to determine the priority of issues in our backlog. Among them is the degree of impact on our Watermark developers and designers and/or the users of our Watermark products. When reporting an issue or requesting an update or new component or design guideline, please assign one of the following severity levels to help us better understand the impact.

Critical

An issue at the critical level is a blocker for a team, or is unavoidably affecting a large number of users in production, such as:

  • a component will result in incorrect data being displayed or added to the user's database
  • the component breaks the user's workflow
  • a component does not fulfill its fundamental purpose

Major

A major issue is:

  • a defect that seriously impairs users, but for which a workaround exists
  • a defect that may hinder the workflow of a significant number of users
  • new component functionality that a team has on its roadmap for a provided date/iteration
  • a new design pattern or guidelines that a team would like to have by a provided date in order to meet a PI goal

Moderate/Limited

Everything else. There is no impending need or there is no significant impact on users.

In a compound component like Select or Action Menu, child components are rendered in the parent's slot element, part of its shadow DOM tree. Slots essentially serve as a placeholder for markup that you the developer define in the light DOM tree, like <wm-menuitem>, <wm-option>, text content, or other child elements.

The browser distributes the child elements defined in the light DOM into the shadow DOM of the parent. The result is a flattened DOM tree—a merger of the the light DOM and the shadow DOM. This flattened tree is what you see in DevTools and what is rendered on the page.

With the standard implementation of the component, dynamically updating the child items will throw an error. Elm's efficient diffing of the DOM will register that only the child items have changed and try to update them, but the component has already been composed.

Rendering the component in a Keyed node and giving it a dynamic id will cause the entire component, rather than just the child items, to render anew, avoiding the error.