-
Notifications
You must be signed in to change notification settings - Fork 1
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
Minimal front-end for launch #12
Comments
Based on conversation with @jhamman on slack, I should note that we are open to switching frameworks (e.g. move to React) if someone is willing to write, deploy (in time for OSM), and maintain the code. That sounds like a heavy lift to me, but I'd love to be proven wrong! 😉 |
@rabernat - I transferred this issue here so that we can continue the conversation / design conversation. What we have now in this repo is a re-implementation of the Vue site in Next.js. The site now includes a number of new routes including the The site is currently deployed at https://pangeo-forge-org.vercel.app/ The major todo's are:
|
Fantastic Joe. Will you be attending the 2pm meeting today? If so I'll ask you to run through this for the team. |
It would be nice to have a minimal working read-only front-end for when we launch. Basically just a vanilla browse interface for the three data models currently defined in the public API.
bakeries (note that the current API doesn't have enough info on bakeries, see Proposal: eliminate bakeries.yaml - split into database entry and bakery-specific config roadmap#47)
/bakeries/
routes to a paginated, browseable list of bakery cards/bakeries/{name}
details on that bakery, links to its recipesfeedstocks (e.g.
pangeo-forge/noaa-oisst-avhrr-feedstock
)/feedstocks/
routes to a paginated, browseable list of feedstock cards/feestocks/gh/pangeo-forge/noaa-oisst-avhrr-feedstock
is the landing page for that feedstock, within links to connected recipes and datasetsrecipes (technically "recipes runs", but I think recipes is a better name to use on the front end size).
/recipes/
routes to a paginated, browseable list of recipe cards/recipes/{id}
gives details on that recipe run.A recipe may or may not produce a dataset. If so, it will be available via
recipe.dataset_public_url
. I still think we should have a separate browse path for...datasets, even though there is a 1:1 relationship between datasets and recipes, I think many people will just want to browse the data
One way to limit scope and make things easy for us would be to not try to support any search yet. Just read-only browsing through the database contents, with a pretty direct relationship between the API and what's on the screen.
For anyone thinking of picking this up, note that we are using
That should be all that's needed to wire this up.
The text was updated successfully, but these errors were encountered: