-
Notifications
You must be signed in to change notification settings - Fork 900
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Firebase alias commands aren't intuitive #144
Comments
Hey Simeon, Thanks for the detailed feedback! We had quite a bit of discussion about I think we're going to spend some time with this in production to keep gathering feedback, but I'll definitely mark this as a vote for an improved UX and if anyone sees this and agrees, feel free to 👍 with an emoji reaction on the issue above. |
#152 starts to address the intuitiveness of aliasing by automatically activating an alias if only one is available. |
I just spent several hours trying to figure out projects, aliases, the
UPDATE: Just noticed that |
Is this true?
http://stackoverflow.com/a/37402821/210867 UPDATE: It's seems like the Firebase servers are storing whatever string you pass to
Would really like to see a concise and accurate explanation of:
|
Alias mappings are stored in the project directory in So yes, if you move your project directory your "active" project mapping will be lost. |
People on this thread: do you have suggestions as to how you'd like to see
I'm very much open to taking a new approach especially to the command structure, and I'd be very happy to hear about either how you think it should work or other tools that you think do a good job with this. |
That's pretty much exactly the summary I ended up with in my notes after my experimentation session, with one exception - I didn't know about I'm too brain dead at the moment to make useful suggestions, but if some come to me, I'll post them here. |
I'm still a bit unsure if I understand aliases correctly. I was thinking it was for separating parallel phases of development. For example:
I'm toying with it now. I'm hoping this is what it does |
Closing this out as the use command has been established for so long that changes are unlikely. |
I'm a newish Firebase user and I just found myself stumbling over the CLI parameters for aliases. Specifically, I was trying to move my files from one firebase project to another.
The current CLI has users entering
firebase use
to interact with aliases. It makes sense thatfirebase use <alias>
would cause the command line tool to switch which alias it uses, but I found the flags--add
and--unalias
to be unclear and non-semantic.I see two major problems with the current
add
andunalias
flags. First, they don't read well when paired withfirebase use
. The command "firebase use --add foo" could be rephrased as "hey firebase,add
a newuse
calledfoo
." I'm not really sure what a "use" would be, which is what trips me up. Second, "add" and "unalias" aren't complementary (rule 27); the user can't infert that in one case they should "add" and the other they should "unalias". A more symmetric interface would use "add/remove" or "alias/unalias".IMO a more ergonomic interface would use different commands for alias CRUD operations and setting modifying the Firebase runtime's state.
firebase alias --add [<alias> [<project>]]
- Create a new alias named and map it to project . Both and would be optional. If either is omitted, the CLI would prompt the user to provide the name of the alias and the project it should reference (like the current flow).firebase alias --remove [<alias>]
- Unalias the alias named . If is omitted, the CLI would prompt the user to select the alias they wish to remove and to provide final confirmation before removal.firebase use <alias>
ORfirebase alias --use <alias>
- Set Firebase's state to refernce the specified alias.firebase clear
ORfirebase alias --clear
- Clear the current alias from Firebase's state.EDIT: Cleaning up some grammar/missing thoughts.
The text was updated successfully, but these errors were encountered: