Open nikgraf opened 8 years ago
@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.
@okonet totally agree with the UX part.
Some more thoughts:
That's why we came to this decision. I'm happy to change it. Ideally a new solution should cover these two points:
On interesting escape hatch and by the same time a cool new feature would be:
What do you think?
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:
Thoughts?
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.
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.
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 …
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.
good point, this could work well …
@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)