console
console | play.core | |
---|---|---|
11 | 5 | |
107 | 313 | |
10.3% | - | |
9.7 | 10.0 | |
1 day ago | over 1 year ago | |
TypeScript | JavaScript | |
Mozilla Public License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
console
-
Oxide Cloud Computer. No Cables. No Assembly. Just Cloud
>https://console-preview.oxide.computer/
That's pretty cool! The design language is a nice touch for sure.
-
Storybook 8
I've used Storybook during development for a while now and the use case you present is how the Storybook is pitched. I actually agree about the simplicity of discovering the components. What I disagree with, though, is that I can't see value of "develop & test your UI independently from your app" part. It forces me to decouple the state from a component and this in turn adds unnecessary complexity to the architecture.
I'm going to use Oxide console [1] as an example because it has a really good setup of MSW + OpenAPI autogenerated mocks (which means that it doesn't need any complete backend, just a defined contract).
Consider this fairly simple page [2]. If I'm using the Storybook pattern, I'm keeping all of the state outside of the component, which means I now have to manually memoize every single variable defined before the return to make sure that the component doesn't do any unnecessary re-renders. This includes `intervalPicker`, `commonProps`, `setFilterId`, every return of `useDateTimeRangePicker`. With MSW I have benefits not needing the API, testing in real production app, using the same exact mocks for unit tests and development.
[1]: https://github.com/oxidecomputer/console
[2]: https://github.com/oxidecomputer/console/blob/main/app/pages...
- Tailwind CSS v4.0.0 Alpha
-
Remix Vite Is Now Stable
SPA mode (what I assume you mean by BFF mode) is brand new, so almost nobody has used it. However, a close example would be the Oxide web console, which we build as an SPA because we want to serve it as static assets from a Rust backend. It's very close to your suggested stack: React + React Router + Tanstack query + zustand, though importantly we also use React Router's loaders to give the app a better-than-SPA feel on navigations. I do plan on moving it to Remix SPA mode when I get a chance, but like I said the result should be very similar so it's not that high a priority for me. If I were starting from scratch I'd probably use Remix SPA.
Repo: https://github.com/oxidecomputer/console/
Live demo here with in-browser MSW mock API: https://oxide-console-preview.vercel.app
-
Oxide: The Cloud Computer
VPS providers are nice, but they don't provide the same cloud-level capabilities that Oxide offers. Check out the console to get an idea of what I mean (this is a demo with mock data): https://oxide-console-preview.vercel.app/
-
Mock Service Worker(msw) releases 2.0
Yeah, basically. We do it with a function call where the argument to the function is that interface representing all the API endpoints. `makeHandlers` handles parsing path params, query params, and request body and passes them to each endpoint handler. So the runtime validation of request bodies is also generated — we generate a zod schema for each request body in the OpenAPI definition and use it to parse the actual request body that comes in.
big function call https://github.com/oxidecomputer/console/blob/bd65b9da7019ad...
automatic body parsing and argument passing: https://github.com/oxidecomputer/console/blob/bd65b9da7019ad...
When an endpoint gets added to the spec, we can rerun the generator and get type errors in the `makeHandlers` telling us endpdoints are missing.
play.core
-
Let it snow in your terminal
An unrelated version on the ASCII playground (runs in the browser):
https://play.ertdfgcvb.xyz/#/1640473937099
-
Ertdfgcvb
All the fun experiments on https://play.ertdfgcvb.xyz/ remind me of Yugo Nakamura's now-defunct site http://yugop.com/ from back in the early 2000s.
-
Oxide: The Cloud Computer
They are very fun to make as well! I've built my own mini-lib on top of this ASCII rendering library (https://github.com/ertdfgcvb/play.core).
I design them in Monodraw, pass it through a janky converter I wrote that converts text into a json grid of characters. I then render a number of layers that get combined, which is a mix of the static art layer, and others generated from functions that spit out a similar cell based frame.
If you're interested:
What are some alternatives?
orval - orval is able to generate client with appropriate type-signatures (TypeScript) from any valid OpenAPI v3 or Swagger v2 specification, either in yaml or json formats. 🍺
third-party-api-clients - A place for keeping all our generated third party API clients.
meetup-contacts-app-2021 - Modern, structured React application demo with pages, services. An Opinionated React App template for large projects.
terraform-provider-oxide - Oxide Terraform provider
cio - Rust libraries for APIs needed by our automated CIO.
omicron - Omicron: Oxide control plane
moonfire-nvr - Moonfire NVR, a security camera network video recorder
manifold-api - Manifold API Client Bindings
hubris - A lightweight, memory-protected, message-passing kernel for deeply embedded systems.
oxide.ts - TypeScript client for the Oxide API