#Remove localized fields from data?

36 messages · Page 1 of 1 (latest)

proud canopy
#

I've got multiple collections running a 2-way sync with Medusa.
If the locale is default, I want it to send the entire data within a BeforeChange hook. When the locale is not default, I only want it to sync data which is not localized.

So, I'm hoping to use a function that receives the data, collection and locale from within a hook and if locale !== process.env.DEFAULT_LOCALE, remove any fields that have localized: true on them.

I can easily make one that manually works for each individual collection, but figured I'd ask to see if anyone already has a solution, or function already that does this. I'm sure a perfectly reusable function that works with any collection would be quite a bit of work, when considering that you may have many nested items and situations where there are tabs with labels, or names, meaning that the api data returned can be quite different. The idea would be that the api response shape does not change at all; localized fields would simply disappear.

Kind of a long shot I guess 😅 maybe I'm over thinking it and there is a simple solution?

surreal dragonBOT
undone pivot
#

Hey Zephuri. I wonder if you would share your specific medusa payload setup. I am currently considering moving metadata off of medusa into payload and wonder how you solved it in detail.

#

Things like variant management for example

proud canopy
#

I based it off of this example:
https://twitter.com/sebrindom/status/1765678023737827434

I will eventually share a starter repo, but its probably at least a couple months out before I'll be able to get it done. Maybe even a payload-plugin-medusa where everything can be synced

The way I do things more or less is that I have the product data sync to a payload product collection (for the default locale, because my projects are multi-language) and I just add all the extra data I want to store in payload.

To show/display products, I do it all via payload. I just use medusa's api for everything dynamic, like which ids and quantities are in the cart, etc; medusa api is basically all id's and numbers; all the text data and images are from payload; but i sync the payload file url with medusa's thumbnail so that when i view products in medusa, i still have the context of the thumbnail in the dashboard.

eventually i'd like to sync everything, but i haven't gotten that far yet. Its really just a game of repeating the same logic as in that example video

#

im not done creating variant management in payload yet, though I will get to it. technically, its not really necessary to put that much of it in payload, but I want the seamless user experience. it'll just take time to get there

#

if you go down that route and try to implement the 2way sync and you have any issues, feel free to reach out, ill try to help

undone pivot
#

Thanks for the reply. Yeah I am also facing the i18n challenge as well as a very heterogenic set of products from multiple manufacturers with multiple levels of completeness, some which are easy to import and others that require me to use AI magic for texts and images for rewriting, translation and scaling. So far I have local scripts that generate an extended medusa csv but it would be nice to manage things centrally and payload is a much better fit for managing content and metadata than default medusa. I am still pondering wether integrating payload fits the scope or wether we continue with tables since imports and changes are rare once deployed.

#

once the numer of SKUs goes beyond 1000, things get interesting

#

right now i feed things into meilisearch which is my primary display api for the frontend and i wouldnt mind detaching that from medusa as well and relying as little as possible on medusa to handle anything but the business logic

proud canopy
#

at least for me, I had experienced some problematic things with table imports and variants being setup properly with their options; at least in it's current state, I don't trust csv imports on medusa to be bulletproof; im more comfortable working with payload, so at least for me, it's what i'll choose

undone pivot
#

I managed to get this working fine so far, probably lucky :). my primary issue is that it is impossible to explain to someone that they need to put markdown text into metadata fields in medusa for display text and all the languages. And relying on spreadsheet based masterdata makes the whole thing quite archaic. I need to consider this more in depth to make a decision. But it is very good to know that others are working on the same challenge. At least for the self-help group aspect of it .. lol

#

But yeah, a lot of things about medusa are shaky and are a matter of trial and error more often than not. Which is sad, since the entire business logic and workflow is far superior to other solutions.

proud canopy
#

also wanted to mention; its actually quite easy to setup the 2way sync so that if the sync fails on either end, changes are rolled back.

I was a bit uncertain about 2-way sync at first, but it can be bulletproof with medusa workflows

undone pivot
#

2 way sync would only be necessary if products are created or modified in medusa admin though. I think the complexity could be reduced by having payload be the master data source

#

especially if variants are added to the mix. 🤔

proud canopy
#

I would not recommend handling fulfillment in payload; I mean... I guess you could, but getting feature parity with medusa admin would be pretty laborious.

undone pivot
#

no, only regarding product data. i dont see a need right now that would make it necessary to sync data from medusa to payload for product data alone

#

everything else stays in medusa

proud canopy
#

ehh, I get what you mean more; but as far as I know, you can't remove ui elements in medusa's admin, so you'd have to fork and rewrite it, I think? to make it not editable, if you don't want to give clients a list of instructions of which buttons they can press

#

I will say, syncing from payload to medusa is the easiest part

undone pivot
#

using subscribers?

proud canopy
#

no, just webhook

subscribers would be for when you want to push updates to payload based on actions like product create or edit

#

or that video calls them hooks anyway; you really are just making custom api routes, then importing the product service for example and making whatever edits you want, however you see fit

undone pivot
#

ok i need to check this out tomorrow

#

i saw there is a strapi and a sanity plugin around for medusa, this is probably also worth checking out

#

I think i wont get around 2way sync since i need an initial seed from medusa either way

proud canopy
#

that is most of the code on the medusa side. the payload side is literally just this:


export const updateMedusaProduct: CollectionBeforeChangeHook = async ({
  data: payloadData,
  req,
  operation,
}) => {
  if (operation === 'update' && !hasRoles(['medusa'], req.user)) {
    try {
      await medusaApi.patch(
        `/hooks/payload/product/${payloadData.id}`,
        req.locale
          ? removeLocalizedProductData({ data: payloadData, locale: req.locale })
          : payloadData,
      )

      return payloadData
    } catch (error) {
      throw new APIError(req.t('errors:failedMedusaSync'), 400, undefined, true)
    }
  }

  return payloadData
}

that of course just being a tiny bit of it, but you get the idea

image.png image.png
#

(images are medusa, code block is payload)

undone pivot
#

I see, thanks

#

Yeah, looks realistic 🙂

undone pivot
#

@proud canopy Hi there - I was playing around with some ideas of how to best integrate medusa and payload in a way that leverages the advantages of both platforms and I would like to ping pong an idea - since you are working on that too - to hear what you think. I ended up with the conclusion that the cleanest way to approach this is to make payload the catalog master and handle import and export on that side including variant management. Even things like adding multiple variant images are a pain in the ass with medusa and require custom code that only bloats things on the medusa side and my goal is deep down to keep content out of the medusa question altogether and only use it for the business logic and to handle fulfillment related things. I also thought about splitting only content off to payload, but that requires exports and imports to merge data from 2 systems which .. well .. i cant see that being a good idea. With payload as the master for everything that is related to a) product structure (variants) and b) product content, most pain points in using the admin are removed and payload can handle import and export of products itself as it is much easier to handle there as well.

#

the only downside here is that this is basically implementing an entire product CRUD strategy including main product plus variants and requires snynching product ids as well as option and variant ids back to payload.

#

The opposite idea is to manage product catalog and product structure only in medusa while using payload only to augment products and variants with images, richtext etc.. this would take away most of the CRUD interfaces to write but on needs to switch between the apps all the time when managing a catalogue, which makes for a worse UX.. and of course the import and export becomes the complicated part then.

#

Having all the product display specific data in payload would probably also siginificantly enhance the integration in the storefront