Dette er et innlegg om skolisse, et komponentbibliotek av Cory LaViska, men med en vri. Den definerer alle dine standard UX-komponenter: faner, modaler, trekkspill, autofullføringer og mye, mye mer. De ser vakre ut fra esken, er tilgjengelige og kan tilpasses fullt ut. Men i stedet for å lage disse komponentene i React, eller Solid, eller Svelte, etc., oppretter den dem med Nettkomponenter; dette betyr at du kan bruke dem med noen rammeverk.
Noen foreløpige ting
Webkomponenter er flotte, men det er for øyeblikket noen små problemer å være klar over.
Reager
Jeg sa at de fungerer i alle JavaScript-rammeverk, men som jeg har skrevet før, er Reacts støtte for webkomponenter for tiden fattig. For å løse dette, Shoelace faktisk laget omslag bare for React.
Et annet alternativ, som jeg personlig liker, er å lage en tynn React-komponent som aksepterer tagnavnet til en webkomponent og alle dens attributter og egenskaper, og deretter utfører det skitne arbeidet med å håndtere Reacts mangler. Jeg snakket om dette alternativet i et tidligere innlegg. Jeg liker denne løsningen fordi den er laget for å bli slettet. Interoperabilitetsproblemet med Web Component er for øyeblikket løst i Reacts eksperimentelle gren, så når den er sendt, kan enhver tynn Web Component-interoperabel komponent du bruker søkes i og fjernes, slik at du får direkte bruk av Web Component, uten noen React-omslag.
Gjengivelse på tjenersiden (SSR)
Støtten for SSR er også dårlig når dette skrives. I teorien er det noe som heter Deklarativ Shadow DOM (DSD) som vil aktivere SSR. Men nettleserstøtten er minimal, og i alle fall krever DSD faktisk serverstøtte å jobbe riktig, som betyr neste, Remix, eller hva du tilfeldigvis bruker på serveren må bli i stand til noen spesiell håndtering.
Når det er sagt, er det andre måter å få webkomponenter til bare arbeid
med en nettapp som er SSR-dette med noe sånt som Next. Den korte versjonen er at skriptene som registrerer webkomponentene dine må kjøres i et blokkerende skript før koden din blir analysert. Men det er et tema for et annet innlegg.
Selvfølgelig, hvis du bygger noen form for klient-gjengert SPA, er dette et ikke-problem. Det er dette vi skal jobbe med i dette innlegget.
La oss begynne
Siden jeg vil at dette innlegget skal fokusere på Shoelace og dens Web Component-natur, kommer jeg til å bruke Slank for alt. Jeg kommer også til å bruke denne Stackblitz-prosjektet for demonstrasjon. Vi bygger denne demoen sammen, trinn for trinn, men åpne den REPL når som helst for å se sluttresultatet.
Jeg skal vise deg hvordan du bruker skolisser, og enda viktigere, hvordan du tilpasser den. Vi skal snakke om Shadow DOM-er og hvilke stiler de blokkerer fra omverdenen (samt hvilke de ikke gjør det). Vi vil også snakke om ::part CSS-velger – som kan være helt ny for deg – og vi vil til og med se hvordan Shoelace lar oss overstyre og tilpasse de forskjellige animasjonene.
Hvis du finner ut at du liker Shoelace etter å ha lest dette innlegget og vil prøve det i et React-prosjekt, er mitt råd å bruke en innpakning som jeg nevnte i innledningen. Dette vil tillate deg å bruke hvilken som helst av Shoelaces komponenter, og den kan fjernes helt når React sender nettkomponentfiksene de allerede har (se etter det i versjon 19).
Vi introduserer skolisser
Skolissene er ganske detaljerte installasjonsanvisninger. På det enkleste kan du dumpe og tagger i HTML-dokumentet ditt, og det er det. For enhver produksjonsapp vil du sannsynligvis selektivt bare importere det du vil ha, og det er instruksjoner for det også.
Med Shoelace installert, la oss lage en Svelte-komponent for å gjengi noe innhold, og deretter gå gjennom trinnene for å tilpasse det fullstendig. For å velge noe ganske ikke-trivielt, gikk jeg med fanene og en dialog (ofte referert til som en modal) komponenter. Her er litt markering hovedsakelig hentet fra dokumentene:
General
Custom
Advanced
Disabled
This is the general tab panel.
This is the custom tab panel.
This is the advanced tab panel.
This is a disabled tab panel.
Hello World!
Dette gir noen fine, stilige faner. Understrekingen på den aktive fanen animerer til og med fint, og glir fra en aktiv fane til den neste.
Jeg vil ikke kaste bort tiden din på å gå gjennom hver tomme av API-ene som allerede er godt dokumentert på Shoelace-nettstedet. La oss i stedet se på hvordan vi best kan samhandle med og tilpasse disse nettkomponentene.
Interaksjon med API: metoder og hendelser
Ringemetoder og abonnement på hendelser på en nettkomponent kan være litt annerledes enn det du er vant til med ditt vanlige rammeverk, men det er ikke for komplisert. La oss se hvordan.
Tabs
Tabs-komponenten () har en show metode, som manuelt viser en bestemt fane. For å kunne kalle dette, må vi få tilgang til det underliggende DOM-elementet i fanene våre. I Svelte betyr det å bruke bind:this. I React ville det være en ref. Og så videre. Siden vi bruker Svelte, la oss deklarere en variabel for vår tabs forekomst:
let tabs;
…og bind den:
Nå kan vi legge til en knapp for å kalle det:
Det er den samme ideen for arrangementer. Det er en sl-tab-show hendelse som utløses når en ny fane vises. Vi kunne bruke addEventListener på vår tabs variabel, eller vi kan bruke Sveltes on:event-name snarvei.
console.log(e)}>Det fungerer og logger hendelsesobjektene når du viser forskjellige faner.
Vanligvis gjengir vi faner og lar brukeren klikke mellom dem, så dette arbeidet er vanligvis ikke engang nødvendig, men det er der hvis du trenger det. La oss nå få dialogkomponenten interaktiv.
Dialog
Dialogkomponenten () tar en open prop som kontrollerer om dialogen er ... åpen. La oss erklære det i vår Svelte-komponent:
let tabs;
let open = false;
Det har også en sl-hide hendelse for når dialogen er skjult. La oss passere vår open støtte og binde til hide hendelse slik at vi kan tilbakestille den når brukeren klikker utenfor dialogboksen for å lukke den. Og la oss legge til en klikkbehandler til den lukkeknappen for å angi vår open støtte til false, som også vil lukke dialogen.
open = false}>
Hello World!
Til slutt, la oss koble opp vår åpne dialogknapp:
Og det er det. Å samhandle med et komponentbiblioteks API er mer eller mindre enkelt. Hvis det var alt dette innlegget gjorde, ville det vært ganske kjedelig.
Men Shoelace - bygges med webkomponenter - betyr at noen ting, spesielt stiler, vil fungere litt annerledes enn vi kanskje er vant til.
Tilpass alle stilene!
Når dette skrives, er Shoelace fortsatt i beta, og skaperen vurderer å endre noen standardstiler, muligens til og med å fjerne noen standardinnstillinger helt, slik at de ikke lenger overstyrer vertsapplikasjonens stiler. Konseptene vi skal dekke er relevante uansett, men ikke bli overrasket om noen av Shoelace-spesifikasjonene jeg nevner er annerledes når du skal bruke den.
Så fine som Shoelaces standardstiler er, kan vi ha våre egne design i nettappen vår, og vi vil at UX-komponentene våre skal matche. La oss se hvordan vi gjør det i en webkomponentverden.
Det vil vi faktisk ikke prøve forbedre hva som helst. Shoelace-skaperen er en langt bedre designer enn jeg noen gang kommer til å bli. I stedet skal vi bare se på hvordan endring ting, slik at du kan tilpasse deg dine egne nettapper.
En rask omvisning i Shadow DOMs
Ta en titt på en av disse faneoverskriftene i DevTools; det skal se omtrent slik ut:
Vårt faneelement har laget en div beholder med en .tab og .tab--active klasse, og en tabindex, mens vi også viser teksten vi skrev inn for den fanen. Men legg merke til at den sitter inne i en skygge rot. Dette tillater webkomponentforfattere å legge til sine egne markeringer til webkomponenten samtidig som det gir et sted for innholdet we gi. Legg merke til element? Det betyr i utgangspunktet "legg inn det innholdet brukeren gjengitt mellom Web Component-taggene her.».
Så komponenten lager en skyggerot, legger til noe innhold til den for å gjengi den pent stilte faneoverskriften sammen med en plassholder () som gjengir innholdet vårt inne.
Innkapslede stiler
Et av de klassiske, mer frustrerende problemene innen webutvikling har alltid vært stiler brus til steder hvor vi ikke vil ha dem. Du kan bekymre deg for at noen stil regler i applikasjonen vår som spesifiserer noe sånt som div.tab ville forstyrre disse fanene. Det viser seg at dette ikke er et problem; skyggerøtter innkapsler stiler. Stiler fra utenfor skyggeroten påvirker ikke hva som er inne i skyggeroten (med noen unntak som vi skal snakke om), og omvendt.
Unntakene fra dette er arvelige stiler. Du trenger selvfølgelig ikke bruke en font-family stil for hvert element i nettappen din. I stedet kan du spesifisere din font-family en gang, på :root or html og få det til å arve overalt under det. Denne arven vil faktisk også gjennombore skyggeroten.
Egendefinerte CSS-egenskaper (ofte kalt "css-variabler") er et relatert unntak. En skyggerot kan absolutt lese en CSS-egenskap som er definert utenfor skyggeroten; dette blir aktuelt om et øyeblikk.
De ::part velger
Hva med stiler det ikke arve. Hva om vi ønsker å tilpasse noe som cursor, som ikke arver, på noe inne i skyggeroten. Er vi sjanseløse? Det viser seg at vi ikke er det. Ta en ny titt på faneelementbildet ovenfor og dets skyggerot. Legg merke til part attributt på div? Det lar deg målrette og style det elementet fra utenfor skyggeroten ved hjelp av ::part velger. Vi skal gå gjennom et eksempel er litt.
Overordnede skolisserstiler
La oss se hver av disse tilnærmingene i aksjon. Per nå, mye av skolisserstiler, inkludert fonter, mottar standardverdier fra egendefinerte CSS-egenskaper. For å justere disse skriftene med applikasjonens stiler, overstyr de aktuelle egendefinerte rekvisittene. Se dokumentene for informasjon om hvilke CSS-variabler Shoelace bruker, eller du kan ganske enkelt inspisere stilene i et gitt element i DevTools.
Arve stiler gjennom skyggeroten
Åpne app.css fil i src katalogen til StackBlitz-prosjektet. på :root seksjonen nederst, bør du se en letter-spacing: normal; erklæring. Siden letter-spacing eiendom er arvelig, prøv å angi en ny verdi, som 2px. Ved lagring vil alt innhold, inkludert faneoverskriftene som er definert i skyggeroten, justeres tilsvarende.
Overskrive Shoelace CSS-variabler
De komponent leser en --indicator-color Egendefinert CSS-egenskap for den aktive fanens understreking. Vi kan overstyre dette med noen grunnleggende CSS:
sl-tab-group {
--indicator-color: green;
}Og akkurat som det har vi nå en grønn indikator!
Spørre deler
I versjonen av Shoelace jeg bruker akkurat nå (2.0.0-beta.83), har enhver ikke-deaktivert fane en pointer markøren. La oss endre det til en standardmarkør for den aktive (valgte) fanen. Vi så allerede at element legger til en part="base" attributtet på beholderen for faneoverskriften. Også den valgte fanen mottar en active Egenskap. La oss bruke disse faktaene til å målrette den aktive fanen, og endre markøren:
sl-tab[active]::part(base) {
cursor: default;
}Og det er det!
Tilpasse animasjoner
For litt glasur på den metaforiske kaken, la oss se hvordan Shoelace lar oss tilpasse animasjoner. Skobånd bruker Web Animations API, og avslører en setDefaultAnimation API for å kontrollere hvordan ulike elementer animerer deres ulike interaksjoner. Se dokumentene for detaljer, men som et eksempel, her er hvordan du kan endre Shoelaces standarddialoganimasjon fra å utvide seg utover og krympe innover, til i stedet å animere inn fra toppen og slippe ned mens du gjemmer deg.
import { setDefaultAnimation } from "@shoelace-style/shoelace/dist/utilities/animation-registry";
setDefaultAnimation("dialog.show", {
keyframes: [
{ opacity: 0, transform: "translate3d(0px, -20px, 0px)" },
{ opacity: 1, transform: "translate3d(0px, 0px, 0px)" },
],
options: { duration: 250, easing: "cubic-bezier(0.785, 0.135, 0.150, 0.860)" },
});
setDefaultAnimation("dialog.hide", {
keyframes: [
{ opacity: 1, transform: "translate3d(0px, 0px, 0px)" },
{ opacity: 0, transform: "translate3d(0px, 20px, 0px)" },
],
options: { duration: 200, easing: "cubic-bezier(0.785, 0.135, 0.150, 0.860)" },
});Den koden er i App.svelte fil. Kommenter den for å se den originale standardanimasjonen.
Innpakning opp
Shoelace er et utrolig ambisiøst komponentbibliotek som er bygget med webkomponenter. Siden webkomponenter er rammeuavhengige, kan de brukes i ethvert prosjekt, med hvilket som helst rammeverk. Med nye rammeverk som begynner å komme ut med både fantastiske ytelsesegenskaper, og også brukervennlighet, har muligheten til å bruke widgets for brukeropplevelse av høy kvalitet som ikke er knyttet til ett rammeverk aldri vært mer overbevisende.
