Sejauh yang saya pahami, pendekatan dari FAST menetapkan beberapa nilai default dan menyediakan cara untuk menyesuaikan token desain dengan mengizinkan untuk mengganti nilai tertentu. Namun, saya bertanya-tanya apakah ini pendekatan yang tepat untuk kami karena kami secara aktif melarang modifikasi sebagian besar token di area lain (misalnya dengan menggunakan variabel SASS alih-alih properti khusus, menggunakan Shadow DOM, dll.). Jadi untuk menerapkannya seperti ini, kita perlu mengubah cara kita menggunakan token desain kita secara umum karena FAST tampaknya menggunakan properti khusus hampir di semua tempat. Jika kami ingin mencegah pengguna mengganti token, saya pikir komponen ini seharusnya hanya bertanggung jawab untuk mengatur tema dan gaya default yang diperlukan sehingga satu-satunya input adalah tema dan mungkin beberapa opsi tingkat tinggi lainnya seperti ini: https:// fasihsite.z22.web.core.windows.net/components/provider/definition

Saya pikir @tomheller memiliki pendapat yang kuat tentang itu.

Pemahaman saya tentang penyedia sistem Desain adalah menangani beberapa nilai default sehingga pengguna tidak harus mengaturnya di setiap komponen. seperti tema dll..

Lebih jauh, itu harus mengurus pengiriman beberapa gaya dasar sehingga bukan komponen yang harus mengurusnya. IMO kami dapat menentukan bahwa ketika Anda ingin menggunakan komponen dengan benar, Anda harus membungkusnya di penyedia karena penyedia menetapkan default yang diperlukan.

Ya, penyedia sistem desain berisi beberapa default yang akan diberikannya ke masing-masing komponen di dalam slotnya.
Beberapa properti ini dihitung dalam penyedia sistem desain (dalam contoh FAST. Di sinilah input unit desain berjalan... ia menghitung jarak tertentu dll...).
Saya pikir ini adalah pendekatan yang baik untuk dilihat. Saya semakin tidak yakin tentang penggunaan variabel sass di sini. Pada titik ini, kami tidak dapat menggunakan variabel sass di komponen kami, dengan memiliki semua token yang tersedia sebagai properti khusus akan membuat banyak hal menjadi lebih mudah.

Pertimbangkan pembungkus tata letak, yang dapat mengubah jarak berdasarkan satu input layout ='loose|dense' . Melarang perubahan token seharusnya tidak menjadi tujuan utama kami saat ini.

Proposal API

Ringkasan

fluid-provider memastikan bahwa semua properti yang diperlukan diatur untuk menampilkan komponen anak dengan benar. Ini memungkinkan mengonfigurasi tema dan kerapatan tata letak (jarak relatif) komponen anak.

Komponen ini tidak menerapkan tata letak apa pun, jadi warna latar belakang halaman harus disetel di elemen lain di dalam penyedia jika diinginkan.

API

penyedia cairan

Properti dan nilai default:

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

Acara:

tidak ada

Prototipe 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>

Saya pikir penyedia seharusnya tidak menerapkan tata letak yang sebenarnya. Saya akan menghapus properti display-background .

Baiklah, saya akan menambahkan komentar bahwa wadah dengan warna latar belakang harus dibuat secara manual.

Tidak yakin bagaimana rebinding spasi seharusnya bekerja. Mungkin mendefinisikan properti baru layout--small , layout--medium , layout--large yang sesuai dengan token spasi dan hanya menerapkannya ke beberapa spasi (misalnya padding vertikal pada tombol). Itu bisa "menggeser" spasi sesuai dengan pengaturan sehingga layout--medium == spacing--small jika tata letak dense digunakan. Dengan tata letak default , tidak akan ada perbedaan antara spacing--medium dan layout--medium .

Saya lebih suka melihat sesuatu yang menggunakan beberapa logika yang memiliki satu set spasi default, dan ketika diatur ke padat, itu runtuh/membagi nilai token spasi menjadi kurang. Yaitu

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`;
} 
// ...

Ini jelas beberapa kode yang cacat, tapi saya kira idenya muncul. Saya tidak tahu bagaimana memberikan properti khusus terbaik pada elemen khusus.
Selain itu, kami mungkin memerlukan impor nilai tanpa unit untuk dapat menerapkan perhitungan.
Tapi inilah yang menurut saya juga dilakukan oleh penyedia cepat.

Kami akan menutup masalah ini karena komponen web tidak seperti yang kami inginkan untuk membuat komponen di masa depan, ini terkait dengan pergeseran prioritas dalam tim.