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

RFC: Deprecate @faustwp/blocks and introduce CLI tool to scaffold blocks #1961

Open
jasonbahl opened this issue Sep 20, 2024 · 1 comment
Open
Labels

Comments

@jasonbahl
Copy link
Contributor

Problem

The @faustwp/blocks package currently provides components and associated queries for blocks and allows users to import these components and queries for use within their pages.

The problem with this approach is that the queries and components live within a remote NPM package and when the GraphQL schema changes (i.e. when WordPress 6.3 changed attribute names on blocks, or anything else causes the schema to change) users are stuck waiting for the remote package to see an update.

Proposal

Instead of installing @faustwp/blocks as a dependency, I think it would be nice to offer a CLI tool for users to scaffold out blocks that live in their codebase (similar to @shadcn/ui).

This way users are able to get started quickly using blocks in their codebase, but ultimately maintain control over the blocks and their associated queries. When their schema changes, they can update their codebase. Additionally they can make other tweaks to the components such as tie them in with tailwind or another styling framework that meets their sites needs.

The way I see it is that we can offer something like a faust scaffold blocks command (or similar) that would then prompt the user to select some options (i.e. which blocks to include/exclude, maybe whether to use tailwind or not, etc) then it would generate blocks in the wp-blocks directory for them that they would then be able to customize and tweak for their project(s).

Benefits

  • Quick start: users can get started using blocks quickly
  • Components and Queries live in the end users versioned code, closer to the schema being queried (users not waiting for a 3rd party package update to adapt to their schema)
  • Users can customize the queries and components directly

Tradeoffs

  • Individual projects need to update their queries / components in their codebase (vs updating an npm package)
@jasonbahl jasonbahl added the RFC label Sep 20, 2024
@josephfusco josephfusco pinned this issue Sep 23, 2024
@rodrigo-arias
Copy link

I really like this idea. The only reason I hadn’t migrated to this package earlier was precisely because of the drawbacks mentioned here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants