WIP for Review: String File Formats

[bparrish17]

Overview

TL;DR: The pull command runs the relevant formatter for each output.

The existing JSON format remains unchanged, it pulls from GET /v2/textItems and GET /v2/components and then iterates over each returned value to get configured variants.

For the new formats we had to get all the data directly from the API. This lead to the creation of the BaseExport formatter class. This iterates over the configured projects/component folders/variants etc. to then fetch the relevant files and write them to the configured directory.

What to Review

• Check out the BaseExport formatter and how it fits with the pull command. Does it make sense? Does it account for possible future features?
• Check out the individual formatters extending BaseExport
• Test with your own projects/files by running the steps below. Do the outputs appear as you would expect given your config/environment?

Questions to Answer

• Do you have any concerns with updating the existing JSON format to use the new BaseExport formatter style instead of the current one defined in JSONFormatter?
• Are there any future features or other items you worry this new structure may not account for?
• Are there potential customer configurations you think may need to be accounted for that aren't already being considered?
• Do the relevant API Additions account for future needs? e.g. variant status filtering

Test Plan/Setup

Setup:

1. Make sure you have a .env with the following content:

DEBUG=true
DITTO_API_HOST=http://localhost:3001

2. 🚨 Make sure you're working off of the backend branch with the relevant API changes: https://github.com/dittowords/ditto-app/pull/8188

3. Get a robust sample config setup that let's you check out the different formats, for example

projects:
  - id: <project-A>
  - id: <project-B>
variants:
  - id: base
  - id: spanish
  - id: japanese
components:
  folders:
    - id: root
outputs:
  - format: json
     framework: i18next
     outDir: "./ditto/json
     
  - format: android
    outDir: "./ditto/android"

  - format: ios-strings
    outDir: "./ditto//ios-strings"

  - format: ios-stringsdict
    outDir: "./ditto/ios-stringsdict"

Run yarn sync at the root of the CLI directory, this should pull from your local Ditto environment

[asnewman]

Do you have any concerns with updating the existing JSON format to use the new BaseExport formatter style instead of the current one defined in JSONFormatter?

Nothing comes to mind. Are you planning to implement this change in a separate PR? (that would make sense to me!)

[bparrish17]

Do you have any concerns with updating the existing JSON format to use the new BaseExport formatter style instead of the current one defined in JSONFormatter?

Nothing comes to mind. Are you planning to implement this change in a separate PR? (that would make sense to me!)

Yep! That would be a fast follow, also notably in a separate CLI version release after the file formats one

[asnewman]

All my stringsdict files seem to be empty 🤔 Do you get this too?

[bparrish17]

All my stringsdict files seem to be empty 🤔 Do you get this too?

Yep that's expected! .stringsdict files are specifically for plurals. If you use the new plurals feature flag in the FE to create some test data you can see those examples outputted in the stringsdict files

[marla-hoggard]

I didn't test but in general things all make sense to me! The one thing I don't love about how this differs from the initial JSON implementation is that this results in potentially a very large number of individual requests being sent off all at once, while the JSON formatter only needs to make a few requests no matter what parameters we use.

On the one hand, that large, combined response could suffer from its own response size issues, but seeing that distinct difference has me leaning towards leaving the JSON code as is vs updating it to match the other exports. (And we can always add pagination to handle the potential response size issue.)

Consistency is good but unless we get a customer request to make the JSON files available via the API, I don't think it's worth the effort to create new export endpoints for the JSON files, which is what would be required to get that implementation in line with these.

[bparrish17]

I didn't test but in general things all make sense to me! The one thing I don't love about how this differs from the initial JSON implementation is that this results in potentially a very large number of individual requests being sent off all at once, while the JSON formatter only needs to make a few requests no matter what parameters we use.

On the one hand, that large, combined response could suffer from its own response size issues, but seeing that distinct difference has me leaning towards leaving the JSON code as is vs updating it to match the other exports. (And we can always add pagination to handle the potential response size issue.)

Consistency is good but unless we get a customer request to make the JSON files available via the API, I don't think it's worth the effort to create new export endpoints for the JSON files, which is what would be required to get that implementation in line with these.

Yeah totally. I think we're actually going to punt on any changes to the initial JSON implementation. Everything is in a totally good state, and despite the separate implementations IMO is pretty readable and easy to follow. Might be something we wanna do down the road but will be leaving for now!