Shopify POS s-pos-list: liste virtualizate în extensii, din 2026

Shopify a introdus în API-ul POS UI extensions versiunea 2026-10 componenta s-pos-list, o listă virtualizată pentru Polaris web components. Rândurile se trimit ca date simple, iar fiecare tip de rând are propriul template. Ea înlocuiește vechiul List, disponibil până la versiunea 2025-07, și rulează pe Shopify POS 11.17.0 sau mai nou. Pentru extensiile care nu adoptă noua versiune, nimic nu se schimbă.

Ce s-a schimbat, concret

Vestea vine de la Shopify Changelog, pe 22.10.2026 (sursa). Pe scurt: componenta List s-a oprit la versiunea de API 2025-07, iar Polaris web components rămăsese fără un echivalent. s-pos-list umple acel gol.

Diferența de fond nu e doar tehnică. Vechiul List avea un layout fix de rând. Noul s-pos-list lucrează cu template-uri pe tip de rând, ceea ce înseamnă că într-o singură listă poți combina titluri de secțiune, separatoare și rânduri de conținut. Pentru un dezvoltator, asta înseamnă mai puțin cod de lipit și mai mult control asupra felului în care arată fiecare categorie de informație.

Cine e afectat: extensiile care setează api_version = "2026-10" și rulează pe Shopify POS 11.17.0 sau mai nou. Versiunile 2026-07 și anterioare nu includ componenta. Extensiile care rămân pe versiuni vechi sau care continuă să folosească List funcționează neschimbat. Shopify spune explicit că nu e nevoie de nicio acțiune obligatorie.

Motivul pentru care componenta există e mai interesant decât anunțul în sine. Mulți dezvoltatori construiau liste lungi prin maparea rândurilor într-un s-scroll-box. Problema: POS-ul crea un view pentru fiecare rând, deci timpul de afișare și memoria creșteau odată cu lista. La liste foarte mari, afișarea putea chiar eșua. s-pos-list reciclează view-urile pe măsură ce utilizatorul derulează. În testele Shopify pe un iPad (A16), cu cel mai complex layout de rând din vechiul List, noua componentă afișează și derulează liste mari la fel de rapid ca List din 2025-07.

De ce contează virtualizarea pentru un magazin cu volum

Aici e partea care merită citită de oricine are un magazin fizic cu POS. O listă de produse, de comenzi sau de clienți nu e o problemă când ai 50 de rânduri. Devine o problemă când ai câteva mii și un angajat care stă cu tableta în mână în fața clientului.

Timpul de încărcare a unei liste în POS nu e o metrică de dashboard. E o metrică de coadă la casă. Dacă ecranul se blochează două secunde când cauți un produs, clientul simte asta. Dacă lista nu se încarcă deloc, vânzarea se mută în altă parte sau se amână.

Virtualizarea rezolvă exact această clasă de probleme: nu mai ții în memorie un view pentru fiecare rând, ci doar pentru cele vizibile plus o marjă. E o abordare standard în UI-urile moderne, dar lipsea din toolkit-ul POS pentru extensii. Faptul că Shopify o livrează ca web component, nu ca feature ascuns, înseamnă că și extensiile terțe o pot folosi.

Un detaliu important din comunicare: testul de performanță compară s-pos-list cu List din 2025-07, nu cu s-scroll-box. Adică reperul e „cel puțin la fel de rapid ca ce era bun înainte", nu „mai rapid decât orice". E o promisiune rezonabilă, dar nu una spectaculoasă. Cine are acum liste lente făcute cu s-scroll-box ar trebui să vadă o diferență reală. Cine venea de pe List nu câștigă viteză, câștigă flexibilitate de layout și compatibilitate cu viitorul.

Maparea de la List la s-pos-list: ce trebuie schimbat în cod

Shopify a publicat un tabel de mapare, iar câteva puncte sunt esențiale pentru cine face migrarea:

• Datele rândurilor: în loc de structura veche, trimiți un array de rows. Fiecare rând își păstrează id-ul și primește un templateFor. Template-ul se construiește din componente precum s-image, s-text, s-badge și s-switch.
• Interacțiunea pe rând: onPress de pe rând devine onRowClick pe listă, iar rândul se citește din event.detail.item. Pentru rândurile care nu aveau onPress, se folosește un template de tip text.
• Încărcarea incrementală: isLoadingMore și onEndReached devin loadingMore și onLoadMore.
• Header-ul listei: listHeaderComponent devine un element copil cu slot="header", de exemplu un câmp de căutare. Ca și înainte, derulează împreună cu rândurile.
• Titlul: title devine un s-heading deasupra listei, care rămâne fix cât timp rândurile se derulează.
• Imaginile: imageDisplayStrategy dispare ca strategie globală. Acum template-ul tău decide. Regula practică: randează mereu zona de imagine sau înfășoar-o într-un condițional pe un câmp al rândului.

Recomandarea Shopify e să testezi pe POS 11.17.0 sau mai nou și să confirmi că listele lungi încă se încarcă și se derulează corect. Asta nu e o formalitate. Migrarea atinge structura de date, evenimentele și header-ul, deci un test pe dispozitiv real e obligatoriu înainte de a împinge în producție.

Ce înseamnă pentru tine, antreprenor sau marketer român

Dacă ai un magazin online pe Shopify și vinzi și fizic, prin POS, schimbarea te privește indirect, dar te privește. Nu tu scrii codul, ci furnizorul extensiei pe care o folosești: loialitate, gestiune de stoc, programări, catalog extins, tot ce rulează în spatele ecranului de vânzare.

Întrebarea pe care trebuie să o pui furnizorului nu e „ați implementat s-pos-list?". E mai simplă și mai utilă: „extensiile voastre mai folosesc List sau s-scroll-box pentru liste lungi, și pe ce versiune de API rulați?". Dacă răspunsul e „suntem pe 2026-07 sau mai vechi", nu e o problemă imediată, pentru că nimic nu se strică. Dar e un semnal despre cât de repede vor ajunge la componentele noi.

Al doilea lucru de urmărit e performanța la volum. Dacă magazinul tău are un catalog de câteva mii de SKU-uri și vânzătorii caută produse în POS, o listă care se încarcă greu e o problemă de conversie, nu de IT. Nu ai nevoie de un audit tehnic ca să observi asta: stai lângă casă într-o zi aglomerată și cronometrează cât durează până apare produsul căutat.

Aici se leagă și discuția mai largă despre cum măsori ce se întâmplă în magazin. Dacă nu ai un mod clar de a urmări unde se pierde vânzarea, poți avea impresia că problema e traficul, când de fapt e fricțiunea din POS. Merită citit în paralel materialul despre de ce mai puțin engagement poate fi semnal de succes în AI shopping, pentru că logica e aceeași: nu toate semnalele bune arată ca o creștere vizibilă în dashboard.

Un al treilea lucru, de perspectivă: Shopify își ține promisiunea de compatibilitate. Extensiile vechi continuă să funcționeze, iar migrarea e opțională. Asta e important pentru un comerciant care nu vrea surprize în plin sezon. În schimb, cine vrea funcții noi trebuie să urce versiunea de API, iar asta cere un furnizor activ. Aici intervine întrebarea de business: cât de departe în urmă e stack-ul tău de POS față de ce livrează platforma?

Limitele anunțului și ce rămâne de verificat

Anunțul e clar, dar nu răspunde la tot. Nu spune când vor migra extensiile terțe, nu spune dacă List va fi eliminat definitiv la o versiune viitoare și nu oferă cifre despre cât de des eșuau listele mari în practică. Testul de performanță e pe un singur dispozitiv, un iPad A16, cu cel mai complex layout de rând din List. E un reper util, dar nu o dovadă că pe hardware mai vechi sau pe Android comportamentul e identic.

De asemenea, formularea „la fel de rapid ca List din 2025-07" trebuie citită exact. Nu e o promisiune de îmbunătățire față de List, ci de paritate. Îmbunătățirea reală se vede la cei care veneau de pe s-scroll-box.

Dacă furnizorul tău de extensii îți spune că „totul e ok", cere detalii: ce versiune de API folosesc, ce componente pentru liste lungi și dacă au testat pe POS 11.17.0. Un răspuns vag nu dovedește absența problemei, dar nici nu o exclude. Verificarea completă cere confirmare tehnică, nu doar încredere.

FAQ

Trebuie să fac ceva cu extensiile mele dacă nu sunt dezvoltator? Nu. Shopify spune explicit că nu e nevoie de nicio acțiune. s-pos-list e o componentă nouă, iar extensiile existente funcționează neschimbat. Întrebarea utilă e pentru furnizorul extensiilor tale, nu pentru tine.

Funcționează s-pos-list pe orice versiune de Shopify POS? Nu. Are nevoie de Shopify POS 11.17.0 sau mai nou și de o extensie setată pe api_version = "2026-10". Pe versiunile de API 2026-07 și anterioare componenta nu există.

Ce se întâmplă cu vechiul List? Se oprește la versiunea de API 2025-07. Extensiile care rămân pe versiuni vechi sau care continuă să folosească List nu se schimbă. Nu există un termen anunțat pentru eliminarea completă.

Arc final: AI-ul ajută, omul decide, agenția execută

Unelte bune de POS și componente bine gândite elimină fricțiunea. Dar niciun API nu îți spune ce să faci cu timpul câștigat. AI-ul poate analiza unde se pierde vânzarea, poate compara versiuni de extensii și poate pregăti un plan de migrare. Decizia despre ce testezi, în ce ordine și ce lași pe mai târziu rămâne a media buyer-ului și a omului care răspunde de magazin. Iar pasul concret, de la „am citit anunțul" la „am verificat furnizorul și am un plan", îl face ALLSoft Agency. Fără hype, cu cifre pe masă. Dacă vrei să vezi cum arată o discuție serioasă despre execuție și permisiuni, începe cu Vercel Agent și accesul la producție.