import { json, type LoaderFunctionArgs } from "@remix-run/node";
import { authenticate } from "../shopify.server";
export const loader = async ({ request }: LoaderFunctionArgs) => {
const { billing, session } = await authenticate.admin(request);
// Verifică planul direct în loader ca să eviți renderul unui ecran neautorizat
const hasPayment = await billing.check({
plans: ["PRO_MONTHLY_PLAN"],
isTest: process.env.NODE_ENV !== "production",
});
if (!hasPayment) {
// Shopify cere redirect obligatoriu prin billing.request, nu redirect() clasic
return billing.request({
plan: "PRO_MONTHLY_PLAN",
isTest: process.env.NODE_ENV !== "production",
returnUrl: `https://${session.shop}/admin/apps/${process.env.APP_NAME}`,
});
}
return json({ ok: true });
};Am lansat acum câteva luni o aplicație publică de gestiune stocuri pentru Shopify, care rulează acum pe vreo 420 de magazine active. Stack-ul a fost cel recomandat oficial: Remix (Hydrogen/Node runtime) combinat cu componentele Polaris. Dacă vrei să scoți un app public în App Store și crezi că template-ul oficial generat de CLI e gata de producție, te înșeli amarnic.
Template-ul Remix: bun pentru prototip, ciudat în producție
CLI-ul celor de la Shopify îți generează un proiect Remix care merge brici local. Problema apare când înțelegi cu adevărat cum funcționează iframe-ul din adminul Shopify și autentificarea bazată pe token-uri de sesiune.
Remix e excelent pe partea de server-side rendering și încărcare paralelă de date via loaders. Trade-off-ul e că te lovești constant de restricțiile iframe-ului. De exemplu, navigarea clasică din Remix (<Link>) uneori desincronizează bara de adrese a adminului Shopify dacă nu folosești corect App Bridge. Dacă userul dă refresh la pagină în browser când e într-un sub-meniu, riști să pierzi contextul de sesiune și să-l arunci într-o buclă infinită de redirect-uri OAuth.
Polaris te scapă de design, dar te leagă de mâini
Shopify ține morțiș la consistență vizuală. Dacă folosești Polaris, review-ul vizual trece mult mai ușor pentru că app-ul tău arată 1:1 cu restul panoului de control. Comercianții nu simt că au părăsit Shopify.
Partea proastă? Polaris e incredibil de rigid. În momentul în care ai nevoie de o vizualizare mai atipică – de exemplu, un tabel cu editare inline pe 50 de rânduri sau grafice mai complexe – simți că te bați cu librăria. Nu încerca să suprascrii clasele CSS de la Polaris cu !important; la fiecare update minor din @shopify/polaris o să-ți crape layout-ul. Mergi pe mâna componentelor lor native, chiar dacă uneori trebuie să faci compromisuri de UX.
De ce ne-au picat aplicația la primele două review-uri
Echipa de review a celor de la Shopify este extrem de meticuloasă. Ne-au testat app-ul pe telefoane mobile, pe tablete și pe magazine de test cu date lipsă. Iată cele două motive exacte pentru care am primit respingere:
-
Billing-ul în modul de test și lipsa ecranelor de fallback: Am presupus că reviewerul acceptă plata direct. Ei testează fluxul de anulare, fluxul în care cardul e respins și ce se întâmplă dacă magazinul e în perioada de trial. Dacă dai un ecran alb sau o eroare 500 în loc de o pagină Polaris cu
BannersauEmptyState, te pică instant. -
Webhooks obligatorii de conformitate GDPR: Dacă uiți să configurezi endpoint-urile pentru
customers/data_request,customers/redactșishop/redact, nici măcar nu apuci să vorbești cu un reviewer uman. CLI-ul le bifează în config, dar trebuie să returneze strict status 200 și să fie validate corect HMAC-ul.
O altă problemă des întâlnită este starea de loading. Când datele vin greu din GraphQL Admin API, nu lăsa pagina goală. Folosește componenta SkeletonPage din Polaris în Remix clientLoader sau Suspense, altfel reviewerul va nota că aplicația este blocată.
La finalul zilei, stack-ul Remix + Polaris este cel mai scurt drum către un app aprobat, cu condiția să nu tratezi review-ul ca pe un simplu checklist bifat în grabă. Cât timp v-a luat vouă să treceți de primul app review?