Shopify Polaris 2.0 reiser et praktisk spørsmål for nettbutikker med tilpassede apper: Vil verktøyene teamet bruker hver dag, fortsatt passe inn i den nye administrasjonen? Shopifys nye utseende oppdaterer ikke disse appene automatisk. Før du godkjenner en visuell oppgradering, bør du sjekke hvilket grensesnittbibliotek hver app bruker, og teste de viktigste arbeidsflytene. Et ryddig skjermbilde er fint. Et innkjøpsordreskjema som mister en ulagret endring, er et langt større problem.
Hva Shopify Polaris 2.0 endrer – og hva som forblir uendret
Shopify har lansert en redesignet administrasjon med ny ramme, navigasjon og visuell utforming. I oversikten over den nye administrasjonen tar Shopify utgangspunkt i hvordan nettbutikker bruker plattformen. For butikkteamet er første oppgave å sjekke internt opplæringsmateriell opp mot dagens grensesnitt, fremfor å anta at alle skjermbilder og navigasjonsbeskrivelser fortsatt stemmer.
Den tilhørende utvikleroppdateringen er mer konkret. I kunngjøringen fra 22. oktober opplyser Shopify at Polaris Web Components 2.0 er tilgjengelig via de stabile kanalene på Polaris CDN. Versjonen samsvarer med den nye administrasjonen og er den første hovedversjonen under CDN-ens modell for semantisk versjonering.
Polaris Web Components er Shopifys bibliotek med grensesnittkomponenter for apper. En oppdatering endrer appens grensesnittgrunnlag, ikke nettbutikkens tema. Dette skillet er viktig når noen spør om nettbutikken må redesignes fordi Shopify-administrasjonen ser annerledes ut. Denne kunngjøringen er ingen grunn til å bygge om den kundevendte nettbutikken.
Det er heller ikke en automatisk migrering. Shopify sier uttrykkelig at polaris.js og polaris-1.js fortsatt leverer Polaris 1.1, og at polaris.js aldri går over til 2.x. For å ta i bruk den nye hovedversjonen via dette CDN-oppsettet må utviklerne endre skriptreferansen til polaris-2.js.
Vår anbefaling: Behandle dette som en bevisst beslutning om appvedlikehold. Ikke gjør det til en hastesak uten tegn på et problem, men ikke anta at et filnavn uten synlig versjonsnummer betyr at appen følger alle nye hovedversjoner.
Start vurderingen av Shopify Polaris 2.0 med å avklare appansvaret
Det første nyttige spørsmålet er hvem som faktisk kan endre appen. Nettbutikker omtaler ofte alt i administrasjonen som «Shopify», selv når det er eksterne leverandører eller et internt utviklingsteam som vedlikeholder skjermbildene.
Lag en kort oversikt over appene de ansatte er avhengige av. Noter hvem som har ansvaret, hvilken grensesnittteknologi appen bruker hvis det er kjent, og hvilken oppgave den støtter. Ta også med hvordan de ansatte kan utføre oppgaven dersom appen blir midlertidig utilgjengelig.
- Leverandørstyrte apper: Spør leverandøren om denne versjonen påvirker grensesnittet, og om de ansatte bør forvente endringer. Teamet ditt bør som regel ikke forsøke å endre leverandørens implementasjon.
- Tilpassede apper bedriften eier: Be den vedlikeholdsansvarlige identifisere hvilken Polaris-versjon som lastes inn, og forklare omfanget av den foreslåtte migreringen.
- Apper uten kjent vedlikeholdsansvarlig: Sørg for tilgang til koden og utrullingsprosessen før du bestiller kosmetiske endringer.
- Apper som ikke bruker de aktuelle webkomponentene: Ikke anta at et skriptbytte er nok til å migrere grensesnittet. Disse appene trenger en vurdering av teknologien de faktisk bruker.
Dette er en kartlegging av kompatibilitet, ikke en anledning til å erstatte nyttig programvare. En app med et eldre utseende kan være verdt å beholde hvis den håndterer en krevende driftsoppgave pålitelig. Spørsmålet er om den blir vanskeligere å vedlikeholde, og om den nye versjonen løser et problem teamet faktisk har.
Gi utvikleren en bestilling som dekker mer enn et skriptbytte
For en app som allerede bruker det berørte CDN-oppsettet, høres starten enkel ut: Endre skriptreferansen. Det dokumenterer likevel ikke at alle sidene fungerer riktig etter endringen.
Shopify gir også en konkret instruks for apper bygget med React Router-malen: Angi polarisUrl både i AppProvider og i serverkonfigurasjonen for shopifyApp, og sørg for at verdiene er like. Be utvikleren bekrefte relevante pakkekrav i den fullstendige endringsloggen før implementering. Bestillingen bør spesifisere disse konfigurasjonspunktene, ikke bare si «oppdater Polaris».
Be om en liten endring som er enkel å gjennomgå
Hold migreringen av komponentbiblioteket adskilt fra endringer i forretningslogikken der det er mulig. Hvis dere samtidig skriver om rabattberegninger eller endrer produktimporten, blir det langt vanskeligere å finne årsaken når en test feiler.
Be om en beskrivelse av hva som endres, og hva som forblir uendret. Den bør også omfatte eventuell tilpasset CSS og wrapper-komponenter appen bruker. Overstyringer som tidligere fikk appen til å se riktig ut, fortjener særlig oppmerksomhet når de underliggende komponentene endres.
Utvikleren bør også oppgi hvilken appversjon som er testet, og hvordan dere går tilbake til forrige fungerende versjon. «Vi kan bytte tilbake» er for vagt hvis ingen har sjekket hva utrullingen ellers inneholder.
Avtal akseptansekriterier før arbeidet starter
Et skjermbilde dokumenterer utseendet, ikke brukervennligheten. Formuler akseptansekriterier rundt fullførte oppgaver: En ansatt skal kunne redigere en post, se en valideringsfeil, rette den og lagre. Det lagrede resultatet må samsvare med den tiltenkte endringen.
For en rapporteringsapp med bare lesetilgang vil prioriteringene være annerledes. Sjekk om filtrene fortsatt er forståelige, og om lange verdier fortsatt er lesbare. La appens oppgave styre testene.
Test de krevende situasjonene, ikke bare startskjermen
De fleste interne apper ser fine ut med ryddige demodata. I praksis møter ansatte søk uten treff, uvanlig lange produkttitler og trege svar. Det er slike situasjoner dere bør ta med i vurderingen av migreringen.
Bruk et testmiljø med representative data der det er praktisk mulig. Hold kundenes personopplysninger utenfor skjermbilder og testdata, med mindre det finnes et begrunnet behov og bruken skjer under kontrollerte forhold.
- Skjemaer: Sjekk obligatoriske felt, ugyldige verdier og ulagrede endringer. Bekreft at det fortsatt er tydelig hva hovedhandlingen er.
- Informasjonstette skjermbilder: Prøv lange navn og store resultatsett. Se etter betjeningselementer som blir kuttet av, eller etiketter som ikke lenger forklarer feltene.
- Tastaturbruk: Fullfør en vanlig oppgave uten mus. Sjekk at tastaturfokuset er synlig, og at elementene får fokus i riktig rekkefølge.
- Tilbakemeldinger: Undersøk hva som vises under lasting, ved vellykkede handlinger og ved feil. Ansatte må kunne se om en forespørsel er fullført før de prøver igjen.
- Tilgangsbegrensninger: Test med tilgangene de ansatte faktisk bruker, ikke bare utviklerens konto.
Dette er våre anbefalte akseptansetester, ikke rapporterte feil i Polaris 2.0. Målet er å fange opp problemer i appens integrasjon før de ansatte oppdager dem i en travel arbeidsøkt.
Ta med noen som bruker verktøyet jevnlig. De kan oppdage at en kjent handling har flyttet seg, eller at det er vanskeligere å skille mellom statuser, selv om utvikleren mener siden er teknisk korrekt.
Hold POS-oppdateringer utenfor migreringen av administrasjonsapper
Shopifys kunngjøringer samme dag omfatter også endringer i POS-utvidelser. De er verdt å se nærmere på hvis bedriften vedlikeholder POS-programvare, men de er separate fra innføringen av Polaris CDN-versjonen for administrasjonen.
Shopifys kunngjøring om reaktiv lagringstilgang introduserer shopify.storage.current i API-versjon 2026-10. Funksjonen lar utvidelsens målkomponenter reagere på endringer i lagrede verdier innenfor samme utvidelse på samme POS-enhet. Skriving og sletting bruker fortsatt eksisterende metoder i Storage API.
Det kan gjøre det mulig for en tilpasset lojalitetsvisning å reagere når en bakgrunnskomponent oppdaterer lagrede poeng. Dette bør ikke omtales som synkronisering på tvers av enheter. Hvis en foreslått løsning avhenger av at verdier overføres mellom kasser, dokumenterer ikke denne kunngjøringen alene at det er mulig.
Shopify introduserte også s-pos-list for POS UI-utvidelser i API-versjon 2026-10, tilgjengelig i Shopify POS 11.17.0 og nyere. Den virtualiserte listen tar imot vanlige raddata og tilpassede radmaler. Den erstatter den eldre List-komponenten for utvidelser som tar i bruk den nye versjonen.
For butikken er det viktig å skille mellom arbeidsomfangene. En utvikler som forbedrer en tilpasset POS-liste, kan ha god grunn til å ta i bruk disse verktøyene. Det arbeidet bør ha egne enhetstester og akseptansekriterier. Ingen av POS-kunngjøringene krever endringer i eksisterende utvidelser bare fordi funksjonen nå er tilgjengelig.
Avgjør om dere bør oppdatere nå eller planlegge arbeidet senere
Vi ville prioritert å vurdere en tilpasset administrasjonsapp som brukes mye, særlig hvis de ansatte allerede sliter med inkonsekvente betjeningselementer. En app under aktiv utvikling er også en naturlig kandidat: Den vedlikeholdsansvarlige kan vurdere det nye grunnlaget før det legges til mer grensesnittkode.
Vi ville vært mer forsiktige med en stabil app som sjelden brukes, rett før en viktig salgsperiode. Et avvik i utseendet alene rettferdiggjør sjelden driftsforstyrrelser. Planlegg vurderingen, dokumenter gjeldende avhengighet og gi noen ansvaret for å følge opp.
Kunngjøringen angir ingen dato for når Polaris 1.1 skal stenges ned. Ikke la et vedlikeholdsforslag skape kunstig tidspress rundt en slik frist. Samtidig er fortsatt levering av en eldre versjon ingen grunn til å utsette fremtidig vedlikehold på ubestemt tid.
Den beste bestillingen er enkel: Identifiser de berørte appene, oppdater en kandidat med tydelig avgrenset omfang, og godkjenn først når reelle arbeidsoppgaver er testet og fungerer. Slik kan den nye administrasjonen gi praktisk verdi uten at en komponentoppdatering blir til en unødvendig ombygging.
Viktige punkter
- Polaris 2.0 tas ikke automatisk i bruk av apper som bruker polaris.js eller polaris-1.js.
- Bekreft hvem som har ansvaret for hver app, og hvilken grensesnittteknologi den bruker, før du godkjenner arbeidet.
- Test at ansatte kan fullføre oppgavene sine, også når feil oppstår, fremfor å godkjenne bare ut fra skjermbilder.
- Vurder oppdateringer av POS-utvidelser separat fra migreringen av administrasjonens komponentbibliotek.
Kilder
- POS UI-utvidelser støtter nå reaktiv lagringstilgang
- POS UI-utvidelser 2026-10 får s-pos-list, en virtualisert liste med tilpassede radmaler
- Polaris 2.0 er nå stabil
- Shopify-administrasjonen i ny utforming (2026)
Vil du at vi tar hånd om dette?
Vi er Shopify Premier Partner og jobber med dette hver dag: ytelse, konverteringsoptimalisering og utvikling av nettbutikker som tjener inn investeringen. Bestill en gratis gjennomgang av nettbutikken, så viser vi deg de tre forbedringene vi ville gjennomført først.
Ofte stilte spørsmål
Oppdaterer Shopify Polaris 2.0 tilpassede apper automatisk?
Nei. Shopify opplyser at polaris.js og polaris-1.js fortsatt leverer Polaris 1.1. Apper som bruker dette CDN-oppsettet, må aktivt ta i bruk polaris-2.js for å gå over til den nye hovedversjonen.
Endrer Polaris 2.0 temaet i Shopify-nettbutikken min?
Denne versjonen gjelder grensesnittbiblioteket som apper bruker. Det er ikke en migrering av nettbutikkens tema og krever ingen redesign av den kundevendte nettbutikken.
Hva bør utviklere sjekke i apper bygget med React Router-malen?
Shopify ber utviklere angi polarisUrl både i AppProvider og i serverkonfigurasjonen for shopifyApp, med like verdier. Utviklere bør også sjekke den fullstendige endringsloggen for relevante pakkekrav.
Hvordan bør nettbutikker teste en migrering til Polaris 2.0?
Test vanlige arbeidsoppgaver med representative data og de ansattes ordinære tilganger. Ta med ugyldige skjemaverdier, langt innhold, tastaturnavigasjon og forespørsler som feiler. Kontroller de lagrede resultatene fremfor å stole på skjermbilder.
Er de nye Shopify POS-komponentene en del av Polaris 2.0-oppdateringen for administrasjonen?
Dette er separate lanseringer. Reaktiv lagringstilgang og s-pos-list hører til API-versjon 2026-10 for POS UI-utvidelser og trenger en egen vurdering. Kunngjøringene krever ikke endringer i eksisterende utvidelser.
