Improve the Add Variation Form

[nikgraf]

@okonet has a nice suggestion, but feel free to come up with your own UX: Pressing on the "+" displays input. It is not focused by default, so you can't start typing without focusing it with the mouse firstly... (see next one for even better fix)

[okonet]

@nikgraf you mentioned that currently this will cause troubles with file names. I'm wondering why not just use some generated file names? We could come up with some template for it like, [ComponentName]_variation[1...n].js to resolve this one. This would improve the UX significantly since coming up with a name even before you added a component isn't a perfect workflow IMO.

To me, the whole point of this project is to have some playground where I can play with my component's different states quickly. Having names is nice, but shouldn't be a requirement.

[nikgraf]

@okonet totally agree with the UX part.

Some more thoughts:

• We have to see the file names as IDs in a distributed system as they are checked into Github.
• Changed file names + changes in the same file are way harder to manage/merge in Git when having conflicts.
• If we allow changing file-names people will have a hard life merging.
• We want to have human readable file-names so people easily can identify which variation to change.

That's why we came to this decision. I'm happy to change it. Ideally a new solution should cover these two points:

• Human Readable Filenames
• Conflicts in Git are easy to be merged by Git newbies

On interesting escape hatch and by the same time a cool new feature would be:

• Clone a variation and create a new one with a new name.

What do you think?

[okonet]

My concerns about having filenames as ids is exactly the reason one can't have 2 or more variation with the same title. Right now it also makes it impossible to rename variations without going through git, which is clearly not optimal, keeping in mind the points from above.

This is I think having some generic names like ComponentName_var1 can solve all these issues:

• They are still readable and also imply the order, which IMO is even more useful when looking at the file system
• Conflicts can be resolved easily and we won't get any when changing the variation title in the UI, which is also a plus for me
• You can clone a file and increment a number to create a new variation. This makes is also easy to expsose to CLI tools IMO.

Thoughts?

[nikgraf]

I like the idea of [1...n]. One use-case bothers me:

Two people create 3 variations on their own machine. Both open a PR. The person who now merges master into her/his branch sees them as conflicts. Variation one from person A might be what person B intended to show with the second variation. I believe this is hard to resolve, but just looking at the files or did I miss something here or even missunderstood?

From what I learned incremental keys don't work well in distributed systems and we use UUIDs everywhere. Except you have main service that let's you claim a range of incremental IDs upfront (which we don't have). Another idea by Max was to make the file-name based on the content hash, but then you would end up adding & removing a file every time you just change one thing in a variation.

[okonet]

Sure, incremental keys won't work for such cases. Hashes won't solve it either, having the downsides you mentioned as well. My question if we should optimize for such edge cases. Sounds more like a premature optimization to me... I'd stick with a simplest solution that improves UX for now.

[nikgraf]

hmmm, I believe people working simultaneously on the same codebase and even same component/variations is not an edge case in teams with more then a handful of people. I might be wrong …

[okonet]

My point is: I wouldn't sacrifice the UX of all users in favor of teams optimizations or merge conflict resolution. But I might be wrong either. @nikgraf what were the issues with storing variations in one file? Looks like it should not have those issues?

If this is 1 JSON file, we could use uids for variations, have same names (titles) and even add a custom order parameter, so it doesn't get a lot of changes. So if multiple people will create variations, the only thing to do will be just to merge these changes. I think in most cases the 3-way automatic merge from git will accomplish this.

[nikgraf]

good point, this could work well …