Comment Planeta Huerto a reconstruit six composants natifs de sa page produit pour son app Shopify

Planeta Huerto, un distributeur espagnol de produits de santé et d'alimentation biologique sur Shopify Plus, a reconstruit six composants de page produit pilotés par des metafields sous forme de composants natifs personnalisés, tout en conservant la logique de sa marketplace Mirakl. Le cas montre qu'une page produit très personnalisée peut fonctionner dans une app mobile, à condition que les données et la logique sous-jacentes soient accessibles.

Son catalogue encode dans des metafields et des metaobjects les données vendeur, les prix par paliers, les filtres alimentaires et la logique de collections. Pour choisir entre construire et acheter, et entre une app native ou une app fondée sur une webview, voir notre guide pour transformer une boutique Shopify en app mobile.

Les résultats après le passage au natif

Canal app contre boutique en ligne, 90 premiers jours. Ces résultats ont été observés après le passage de Planeta Huerto d'une app fondée sur une webview à une app native. Ils comparent l'app à la boutique. Ce n'est pas une comparaison contrôlée avant-après. Pour comprendre pourquoi cette distinction compte, voir comment lire les indicateurs d'une app mobile.

« Toutes les statistiques de l'App Store explosent par rapport aux performances passées, du temps où ils utilisaient des webviews. »

Albert MiraDirecteur technique, Planeta Huerto

L'objection : « notre catalogue est trop personnalisé pour une app »

Planeta Huerto est arrivé chez NAPPS depuis une plateforme fondée sur une webview. Si vous ne savez pas si votre propre app fonctionne ainsi, voici comment le diagnostiquer. Les performances n'étaient pas suffisantes pour une marque dont les clients achètent de façon récurrente, mais cette app avait un atout : elle reproduisait chacun des composants personnalisés du site.

C'était là le piège. Ces composants du site étaient sophistiqués, et chacun reposait sur une logique propre construite à partir de metafields, de metaobjects et de calculs spécifiques à l'activité. Six d'entre eux vivaient sur la seule page produit. En plus de cela, Planeta Huerto exploite une intégration à la marketplace Mirakl : un catalogue unique mêle donc des produits qu'il vend et expédie lui-même et des produits de vendeurs tiers, chacun avec son propre vendeur et ses propres règles d'expédition et de livraison.

Le choix peut sembler binaire : garder une app fondée sur une webview ou payer une reconstruction native complète. L'équipe de Planeta Huerto s'attendait à ce que la reconstruction coûte de 2 000 à 3 000 dollars par mois, ou l'oblige à simplifier la page produit pour entrer dans un gabarit. Aucune des deux options ne convenait à l'activité. Ces composants existaient pour une raison.

Les six composants ont été reconstruits nativement et inclus dans le forfait de Planeta Huerto, au lieu d'être facturés comme du développement sur mesure de niveau enterprise.

Les six composants

La page produit de Planeta Huerto comptait six composants distincts pilotés par des metafields. NAPPS les a tous reconstruits en natif. Cet article examine les trois dont les schémas se transposeront probablement à d'autres marques. Les autres montrent l'ampleur du travail.

La distinction qui compte oppose la nouvelle interface native à l'interface existante dotée d'une logique personnalisée par-dessus. Faites cette distinction avant de lancer un développement sur mesure. Pour choisir une plateforme, consultez comment évaluer une plateforme d'apps Shopify.

Deux ont été créés comme nouvelle interface native : la carte d'information vendeur et livraison, et les paliers de remise par quantité. Un a réutilisé un composant natif existant avec une logique personnalisée par-dessus : le carrousel produit intelligent. Les trois autres sont les étiquettes produit à logique propre, le label produit biologique UE et l'ajout au panier avec état.

Le sixième composant, l'ajout au panier avec état, change le bouton pour afficher combien d'unités de cet article se trouvent déjà dans le panier. Cela aide les acheteurs de la marketplace à suivre leurs articles entre vendeurs dans une commande mixte.

Analyse 1 : la carte d'information vendeur et livraison

Affichez dans l'app l'expédition et la livraison propres à chaque vendeur. Les produits de la marketplace bénéficient ainsi de la même information claire sur la page produit que le catalogue en propre.

La carte se place sur la page produit et affiche le nom du vendeur (cliquable, relié à sa collection), le coût d'expédition et une estimation de livraison. La difficulté vient de ce que l'estimation change selon deux variables à la fois :

• Le jour de la semaine. Commande du lundi au jeudi : expédition le lendemain. Commande le vendredi : expédition le lundi. Commande le week-end : expédition le mardi.
• Le type de produit. Les produits en propre suivent un calcul d'expédition. Les produits de la marketplace relèvent d'un autre vendeur et d'autres règles, tirées des metafields produit, des metaobjects vendeur et de l'intégration Mirakl.

NAPPS a rendu le composant réutilisable : il accepte un nombre illimité d'éléments plutôt que trois ou quatre fixes, une icône par élément et une mise en forme en texte enrichi sur le titre et les éléments. D'autres marques l'utilisent désormais pour des certifications produit, des informations de durabilité et des mises en avant de caractéristiques.

Analyse 2 : les paliers de remise par quantité

Gardez l'interface de remise en natif et laissez la marque fournir la logique de prix. Le palier se met à jour sans aller-retour vers le web.

Le composant affiche les paliers de remise sur volume sur la page produit (1 acheté au prix normal, 3 achetés pour 10 % d'économie, 5 achetés pour 20 %) et encourage des paniers plus grands en montrant clairement l'économie. Quatre choses y sont intégrées :

• Un nombre dynamique de paliers, de deux à dix, et non trois fixes.
• Des étiquettes comme « Le plus populaire » ou « Meilleur rapport qualité-prix » sur n'importe quel palier.
• Un suivi de la sélection en direct, pour que le composant sache quel palier est actif quand le client change la quantité.
• Des rappels au clic, qui renvoient l'événement à la logique propre de la marque pour recalculer le prix. L'interface montre les paliers ; la marque possède le calcul. Cette séparation permet à la même interface native de reposer sur des règles de prix totalement différentes d'une marque à l'autre.

Le composant fonctionne avec l'ajout au panier avec état. Toucher un palier déclenche un rappel qui fixe la quantité, puis met à jour le bouton avec le nombre d'unités au panier. L'acheteur choisit « 3 achetés, 10 % d'économie » et voit le panier changer sans rechargement de page. Ce retour est particulièrement utile quand une commande mêle des articles de plusieurs vendeurs.

Analyse 3 : le carrousel produit intelligent

Utilisez la structure du catalogue pour afficher automatiquement des produits liés. La marque fournit la logique tout en réutilisant l'interface existante.

Ce composant a réutilisé un carrousel que NAPPS possédait déjà. La partie personnalisée consistait à choisir quelle collection afficher. Planeta Huerto nomme ses collections par fil d'Ariane : un produit peut donc appartenir à plusieurs à la fois.

• Accueil > Alimentation > Bio > Légumes
• Accueil > Alimentation > Bio
• Accueil > Alimentation

Le carrousel puise dans Légumes, la collection la plus précise, plutôt que dans Alimentation, trop large. La logique compte la profondeur du fil d'Ariane, sélectionne la collection la plus profonde et lit le titre de la rangée dans un metafield personnalisé, dans la langue de l'acheteur. C'est un schéma courant de développement sur mesure : garder l'interface native existante et ajouter de la logique en TypeScript.

async onComponentCreated() {
    // Every component already has the current product in scope.
    const collectionIDs = product.collectionIDs;

    // Fetch collections, including the custom metafield used for the display title.
    const collections = await collectionService.getCollectionsByIDs(
        collectionIDs,
        ["custom.show_title"]
    );

    // Collections are named by breadcrumb, e.g. "Home > Food > Organic > Vegetables".
    const separator = " > ";

    // Find the deepest (most specific) collection this product belongs to.
    let stepsToProduct = 0;
    let mainCollection: Collection | null = null;

    for (const collection of collections) {
        if (!collection?.title) continue;
        const steps = collection.title.split(separator).length;
        if (steps > stepsToProduct) {
            stepsToProduct = steps;
            mainCollection = collection;
        }
    }

    // Guard: if no collection matched, leave the carousel untouched.
    if (!mainCollection) return;

    // Title the row from the custom metafield, in the shopper's language.
    const title = mainCollection.metafields.custom.show_title;
    this.updateState({
        collectionID: mainCollection.id,
        title: `Más productos de ${title}`,
    });
}

L'extrait mobilise trois capacités de la plateforme dont les composants personnalisés ont souvent besoin :

• Le contexte produit global. product est déjà disponible : un composant n'a donc jamais à redemander le produit de la page.
• Les services de données. collectionService (aux côtés de productService et metaobjectService) lit les données Shopify, y compris les metafields nommés, sans écrire d'appels d'API à la main.
• Le contexte de l'app. AppUtils expose des valeurs au niveau de l'app, comme le pays de l'acheteur, utilisé ici pour décider comment doit se lire le titre de la collection.

La note honnête sur la mise en œuvre

Ce chantier a pris environ quatre semaines, plus qu'un lancement NAPPS habituel. Planeta Huerto a été le premier client dont l'app a été construite sur Expresso, la couche de NAPPS qui transforme React et TypeScript en natif. L'équipe a donc étendu des capacités fondamentales de la plateforme pendant la mise en œuvre.

Pendant ces quatre semaines, NAPPS a étendu :

• Le pont entre le code natif (SwiftUI et Jetpack Compose) et la couche React et TypeScript.
• Les services de lecture des données Shopify : collections, produits et metaobjects.
• Des capacités dont l'équipe a confirmé le besoin en cours de projet, comme le rendu de texte enrichi pour la carte d'information, le chargement dynamique d'icônes, les rappels d'événements pour les paliers de remise et le formatage selon la langue pour le carrousel.

Les capacités créées pour ce projet sont devenues des fonctionnalités réutilisables de la plateforme. Depuis, les développeurs de Planeta Huerto ont rejoint le programme en accès restreint d'Expresso et créent eux-mêmes de nouveaux composants natifs pour l'app.

Avant de planifier une migration, confirmez qui possède les comptes développeur et ce qui peut être transféré depuis l'app existante.

À qui cela s'adresse, et quoi faire ensuite

Planeta Huerto parle aux catalogues complexes et de marketplace dont les pages produit s'appuient sur des metafields, des metaobjects et des vendeurs tiers. Une app native n'a pas à vous enfermer dans des gabarits. La logique existante du site peut être transposée quand la plateforme dispose des services, de la couche React et TypeScript et des composants natifs qui la portent.

Si vous pensez que votre catalogue est trop personnalisé pour une app, commencez par cartographier les données et la logique. Identifiez ensuite les parties qui exigent une nouvelle interface et celles qui peuvent réutiliser un composant natif existant.

Découvrez comment des composants natifs personnalisés fonctionneraient pour votre marque. Réservez une démonstration.