azzlack/sanity-plugin-tabs

Best practice: Data "migration" to wrapper-object?

Closed this issue · 3 comments

This is more of an enquiry / request for documentation rather than a code issue. I've been testing out this plugin, looks and works great and hugely improves the UX of our studio. However we have quite a bit of data belonging to fields which up until now have not been wrapped in an object and with the implementation of this plugin that data isn't automatically moved over

e.g. slug becomes tabs.slug, tabs.slug is empty and slug becomes an unknown field containing the pertinent data.

Is there a best practice for moving / "migrating" data from top level to inside a tabs wrapper? (and if not, any way of doing it without manually going through everything?)

I've now dipped my toes in this and instructions would be something like:

To migrate your data to inside a wrapping object, you will need to migrate data using one of the recommended methods here: https://www.sanity.io/docs/migrating-data.

An easy step by step method is to use adapt one document type at a time to use tabs, export data for that tab, modify that export, and import the modified data.
Example using the CLI:

  1. Export data: sanity dataset export <DATASET> <FILENAME> --types <DOCUMENT TYPE>
  2. Expand the generated tarball
  3. Open up data.ndjson, for each line, wrap all the fields that have been moved to tabs inside a tabs wrapper (substitute 'tabs' with whatever field name you are using): "tabs":{"_type":"object",<THE DATA TO MOVE HERE>}. This could ideally be done using search & replace.
  4. Import the data to sanity: sanity dataset import <FOLDER> <DATASET> --replace(where folder is the folder that was created when expanding the tarball)

In order to apply these changes without the need to modify the data structure of the GROQ response, "object destructuring" can be used. Not sure if "object destructuring" is the correct terminology for GROQ (cannot find it in sanity documentation at this point) but here's an example:

Original Query

*[_type == $type]{
    arrayField[]->{
        fieldOne, fieldTwo
    }

Migrated Query

*[_type == $type]{
    arrayField[]->{
        ...tabs{
           fieldOne, fieldTwo
        }
    }

Example Reponse

[
   ...
  {
    "arrayField": [
     {
       "fieldOne": <my data>
       "fieldTwo2: <my data>
     }
    ]
  }
]

The data structure from the response will be identical based on the two examples (even though we added the tabs wrapper object to the latter example, since we're "destructuring it" with the ....

This means that if we wouldn't destructure it, the response would instead look like so (which would require us to modify how we later process and read that data):

[
   ...
  {
    "arrayField": [
     {
       "tabs": {
         "fieldOne": <my data>
         "fieldTwo2: <my data>
       }
     }
    ]
  }
]

The wrapper object is no longer needed, courtesy of Sanity. Will update the docs