search

observablehq / framework

A static site generator for data apps, dashboards, reports, and more. Observable Framework combines JavaScript on the front-end for interactive graphics with any language on the back-end for data analysis.
https://observablehq.com/framework/
ISC License
2.5k stars 120 forks source link

Make project selection interactive again #601

Closed Sylvestre67 closed 9 months ago

Sylvestre67 commented 9 months ago

(Written by @mythmon) Selecting a project, or defining the details of a newly created project, should not require hand-editing the observable.config.ts file.

There have been two proposals for how to do this:

The web UI sounds nice in some cases, and gives us a lot of integration with the rest of the flow (like automatic authentication, and other niceties), but recent experience with the authentication system has shown us that communicating from the browser to the CLI is hard to do reliably.

Instead I suggest we stay entirely on the CLI, with the exception of observable login. There are a lot of tools that we can draw inspiration from (such as Cloudflare's Wrangler and Github's gh). We might continue to roll our own, or use a library like prompts (used in Create), enquirer, inquirer, or @clack/prompts.. Per #606 lets use @clack/prompts.

I don't think we should use a more opinionated library like ink.

mbostock commented 9 months ago

How are you going to show a thumbnail of the project in the command line? And won’t this require re-inventing UI that we already have on the platform, such as the share modal (if you want to set permissions at the same time that you’re deploying a project for the first time)?

I’m all for having CLI-only as a backup for edge cases like running the CLI on a remote machine, but I don’t think we should optimize for that, and I think going this route may discourage us from leveraging the strengths of the platform.

mythmon commented 9 months ago

Projects don't have thumbnails, though I take your point to mean that the web can offer a richer UI than the CLI.

I think that we will end up making a lot of that UI in both places, eventually. That's because if a user starts their journey in one place, I think we should help them stay in that place as long as they want to.

Github's gh has a good example here: its command to create a pull request. It doesn't expose every option available when creating a PR, but it has options for common ones, and an escape hatch to continue on the web.

If a user starts by creating a project on the website, we can give them an easy command to paste into the command line. (or maybe even hooking up a Github repo to deploy without ever touching a CLI). This again keeps them in the environment they started in as much as possible.

mythmon commented 9 months ago

Per #606, anything we build for this issue should probably use @clack/prompts.

mythmon commented 9 months ago

Fixed by #634.