Por lo que tengo entendido, el enfoque de FAST establece algunos valores predeterminados y proporciona una forma de personalizar los tokens de diseño al permitir anular valores específicos. Sin embargo, me pregunto si este es el enfoque correcto para nosotros, ya que estamos prohibiendo activamente la modificación de la mayoría de los tokens en otras áreas (por ejemplo, usando variables SASS en lugar de propiedades personalizadas, usando Shadow DOM, etc.). Entonces, para implementarlo de esta manera, necesitaríamos cambiar la forma en que consumimos nuestros tokens de diseño en general, ya que FAST parece usar propiedades personalizadas en casi todas partes. Si queremos evitar que los usuarios anulen los tokens, creo que este componente solo debería ser responsable de configurar el tema y los estilos predeterminados requeridos, por lo que las únicas entradas serían el tema y tal vez algunas otras opciones de alto nivel como esta: https: // fluentsite.z22.web.core.windows.net/components/provider/definition

Creo que @tomheller tiene una fuerte opinión al respecto.

Mi comprensión del proveedor del sistema de diseño es manejar algunos valores predeterminados para que el usuario no tenga que configurarlos en cada componente. como tematización, etc.

Además, conviene encargarse del envío de algunos estilos base para que no tenga que encargarse el componente. En mi opinión, podemos definir que cuando desee utilizar un componente correctamente, debe envolverlo en el proveedor, ya que el proveedor establece los valores predeterminados necesarios.

Sí, el proveedor del sistema de diseño contiene algunos valores predeterminados que proporcionará hasta los componentes individuales dentro de su ranura.
Algunas de estas propiedades se calculan dentro del proveedor del sistema de diseño (en el ejemplo de FASTs. Aquí es donde va la entrada de las unidades de diseño ... calcula ciertos espaciados, etc.).
Creo que este es un buen enfoque a considerar. Estoy cada vez más inseguro sobre el uso de variables sass aquí. En este punto, no podemos usar las variables sass en nuestros componentes, y tener todos los tokens disponibles como propiedades personalizadas facilitaría muchas cosas.

Considere un contenedor de diseño, que puede volver a vincular los espacios en función de una sola entrada de layout ='loose|dense' . Prohibir los cambios en los tokens no debería ser nuestro objetivo principal en este momento.

Propuesta de API

Descripción general

fluid-provider asegura que todas las propiedades requeridas estén configuradas para mostrar los componentes secundarios correctamente. Permite configurar el tema y la densidad de diseño (espaciado relativo) de los componentes secundarios.

Este componente no aplica ningún diseño, por lo que el color de fondo de la página debe establecerse en otro elemento dentro del proveedor si se desea.

API

proveedor de fluidos

Propiedades y valores predeterminados:

theme: 'abyss' | 'surface' = 'abyss'; // Theme to use inside the provider
layout: 'dense' | 'loose' | 'default' = 'default'; // Layout density

Eventos:

ninguna

Prototipo HTML

<fluid-provider theme="surface" layout="dense">
  <div style="background-color: var(--color-background)"> <!-- A container for the background color should be created manually -->
    <fluid-button>
       ...
    </fluid-button>
  </div>
</fluid-provider>

Creo que el proveedor no debería aplicar el diseño real. Quitaría la propiedad display-background .

Muy bien, luego agregaré un comentario de que un contenedor con el color de fondo debe crearse manualmente.

No estoy seguro de cómo debería funcionar la unión de espaciado. Tal vez defina nuevas propiedades layout--small , layout--medium , layout--large que correspondan a los tokens de espaciado y solo las aplique a algunos layout--medium == spacing--small si se usa dense diseño default , no habría diferencia entre spacing--medium y layout--medium .

Preferiría ver algo que use algo de lógica que tenga un conjunto de espaciados predeterminados, y cuando se establezca en denso, colapsa / divide los valores del token de espaciado a menos. Es decir

import { FLUID_SPACING_SMALL } from '@dynatrace/fluid-design-tokens'`
...
// wherever the custom properties are set within the design-system-provider
if (this.layout === 'dense') {
  this.style.setProperty['--fluid-spacing-sm'] = `{FLUID_SPACING_SMALL * 0.5}px`;
} 
// ...

Obviamente, se trata de un código defectuoso, pero supongo que la idea surge. No sé cómo proporcionar propiedades personalizadas mejor en un elemento personalizado.
Además, probablemente necesitaríamos importaciones de valor sin unidad para poder aplicar los cálculos.
Pero esto es lo que creo que también hace el proveedor rápido.

Cerraremos este tema ya que los componentes web no son la forma en que queremos crear componentes en el futuro, esto está relacionado con un cambio de prioridades en el equipo.