Add support for import/export of 'mappings'

[jrmykolyn]

Proposal:
Currently, URL 'mappings' must be added and removed one-by-one. As a user, I'd like the ability to import and export batches of mappings.

Use Case:
This would allow teams of developers (mine included) to share common mappings via version control.

To Consider:

• Should the imported mappings replace or append the existing records? Should the feature expose both options?
• How will the imported mappings be validated? How will invalid mappings be handled?
• Where/how will the user be given the option to 'import/export' (ie. via a new view, directly within the existing 'mappings' view etc.)?
• Will the user be able to export a subset of their mappings?

---

I'd be happy to take a crack at this.

[jrmykolyn]

@mitchhentges @tomitm 👋

Any thoughts on this?

[mitchhentges]

Hey, sorry for the delay 😅

Should the imported mappings replace or append the existing records? Should the feature expose both options?

Hmm, if we supported appending, I'd be worried about how we'd handle conflicts between new mappings and existing ones 🤔
For an early iteration of the feature, perhaps replacing existing mappings might make the most sense, we'll just have to be clear that it'll wipe out all existing mappings.

How will the imported mappings be validated? How will invalid mappings be handled?

IMHO the cleanest thing would be to:

1. Parsing validation (the mappings be understood)
2. Application validation (the validation we do right now to new mappings)
3. If any mappings fail, show a nice display of which mappings were valid and why, don't import any.

This way, we shouldn't run into a case where a mapping batch is partially imported, since that shouldn't be as useful as a fully-imported batch (kinda like how a database transaction with a failure in the middle probably isn't useful 😆)

Where/how will the user be given the option to 'import/export' (ie. via a new view, directly within the existing 'mappings' view etc.)?

Hmm, I don't have any crisp ideas, perhaps @tomitm might want to chime in. I'm leaning towards having buttons (import, export) in the same line as the "URL TO URL" and "URL TO FILE" buttons that will put the users through the workflow (and each step would be their own views).
The only concern with this approach is that the buttons would be in the "Create a new URL Mapping" section, which is theoretically about creating a single mapping, but we'd be doing batch operations.
I don't have enough creativity flowing to think of a nice alternative yet though 🤔 😆

Will the user be able to export a subset of their mappings?

We could start by making it a full-export, then looping back to subset-export if there's demand by users (or your team!)

[jrmykolyn]

@mitchhentges Thanks for the feedback. If I get some responses re: each of the points above, is this something that I can take on?

[mitchhentges]

I'd absolutely ❤️ some PRs! I've caught up on a side project, so (theoretically) I should ensure that the turnaround time on reviewing isn't as bad as it's been!

So, absolutely, if you're excited to take this on, then I'll be excited to release it 😄

[jrmykolyn]

@mitchhentges Sounds great. Before I collect our notes into success criteria, I have a suggestion re: where we can expose this functionality to the user.

How would you feel about a dedicated 'Import/Export' tab and view (ie. to appear beside the existing 'Mappings' tab)? On this view we could expose the option to import or export mappings to/from a file, or via copy/paste. If it would help, I can spin up a quick UI mock?

[mitchhentges]

I'm a little worried that it would appear independent from "Mappings" (e.g. looks as if it's app-wide import/export). However, maybe that's not a downside, since technically the only configurable state in James is the mappings!

I think that your solution is better than trying to shoehorn an import/export onto the Mappings tab. Sounds phenomenal 👍 😄

[jrmykolyn]

@mitchhentges Apologies, I haven't had a chance to get started on this. I will touch base this week.