Skip to content
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

create new w3console project #225

Closed
travis opened this issue Jan 6, 2023 · 5 comments
Closed

create new w3console project #225

travis opened this issue Jan 6, 2023 · 5 comments
Assignees
Milestone

Comments

@travis
Copy link
Member

travis commented Jan 6, 2023

I think it makes the most sense to create this as an example project in w3ui based on the branch in #208 and then to move to its own repository once that branch lands

@travis travis added this to the w3up phase 2 milestone Jan 6, 2023
@travis
Copy link
Member Author

travis commented Jan 6, 2023

Big open question is: what framework do we use? Currently leaning toward vite + preact but open to other ideas.

Advantages of vite + preact:

  1. we're now using vite across projects and it provides a very nice harness for dev and testing
  2. preact in React-compatibility mode will demonstrate compatibility with React and Preact
  3. this approach will make w3console more easily composable with existing apps, which isn't easy with something like Next.js

@gobengo
Copy link
Contributor

gobengo commented Jan 6, 2023

preact in React-compatibility mode will demonstrate compatibility with React and Preact

React is what we use @web3-storage/website and nft.storage/website today. React has compatability with React. In general, I think it's fair to claim that the addressable audience of devs-who-have-used-react is much bigger than that of devs-who-have-used-preact. So personally I would recommend using 'just react' and not 'preact', or at least would point out that there are no benefits to preact-over-react presented here yet.

with that said, I don't strong object to preact. I'd just recommend getting something functional with just the more common tooling before attempting it with less common tooling.

this approach will make w3console more easily composable with existing apps, which isn't easy with something like Next.js

If composability is a goal, and I think it's a good one, I think a good way of guaranteeing it is to develop it as a component, but demo it inside a component gallery like storybook. If you're demoing something in storybook, it's guaranteed that it's composable. If not, whether the thing is using next.js or vite, it may still be not composable. You can do storybook w/ vite.

If you dev a W3Console component in storybook + vite, we maintain the most optionality for someone else wanting to come along and embed that component in some other project using whatever combination of next/vite/etc or react/preact etc.

@travis
Copy link
Member Author

travis commented Jan 9, 2023

In general, I think it's fair to claim that the addressable audience of devs-who-have-used-react is much bigger than that of devs-who-have-used-preact.

Yep totally agree here - the idea here is that if we use Preact we'll essentially be targetting React and Preact developers at the same time since Preact provides a subset of React's functionality. That said I've never actually used Preact for anything serious, so I'm not 100% sure this is true - @olizilla @yusefnapora I don't remember if either of you has more experience with Preact, but curious about your take here.

I think a good way of guaranteeing it is to develop it as a component, but demo it inside a component gallery like storybook.

Yea this is basically the plan - we'd like to build w3console out of the "Customizable UI" components in #208. I do think we'll still need a new repository to provide basic app structure and chrome for the thing we want to deploy to beta.console.web3.storage but I'd like to push as much of the functionality of that site into the Customizable UI as possible so that it's easy to see how to reuse our work.

I do think it's worth investigating storybook as a dev/test harness for the Customizable and Headless components in w3ui, especially since its support for snapshot testing (https://storybook.js.org/docs/react/writing-tests/snapshot-testing) might be extremely useful for #150

@travis travis self-assigned this Jan 13, 2023
@olizilla
Copy link
Contributor

I want storybook now i'm working on components. I set it up for ipfs-gui and it was worth the effort. I'm going to add it to the examples/react/playground so we can use it to iterate on our components, while keeping all the storybook dependencies out of our packages that are for public consumption.

As Ben pointed out, vite support in storybook is a thing now which is great, and even better, they just landed pnpm support in the upcoming v7 release available under the stroybook@next tag on npm, so i'm going to start there.

see: storybookjs/storybook#13428 (comment)

travis added a commit that referenced this issue Jan 18, 2023
Add storybook scaffolding so we can iterate on our components and all
the states they can be in.

<img width="1427" alt="Screenshot 2023-01-18 at 16 58 32"
src="https://user-images.githubusercontent.com/58871/213245880-9b5c448a-47c2-46a3-85f7-8b12056289da.png">

Uses the beta release of storybook v7 as it has support for pnpm.

Part of #225 - we need this to demonstrate out components in all their
possible states so we can make them good.

License: MIT
Signed-off-by: Oli Evans <oli@protocol.ai>
Co-authored-by: Travis Vachon <travis.vachon@gmail.com>
@travis
Copy link
Member Author

travis commented Jan 25, 2023

this is done in #255, #266, #268, #284 and others. we probably want to move it into its own project at some point, but this is enough for this ticket for now!

@travis travis closed this as completed Jan 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants