Skip to content

Conversation

@magnetised
Copy link
Contributor

@magnetised magnetised commented Sep 4, 2025

From mix help phx.sync.tanstack_db.setup:

# install igniter.new
mix archive.install hex igniter_new

# create a new phoenix application and install phoenix_sync in `embedded` mode
mix igniter.new my_app --install phoenix_sync --with phx.new --sync-mode embedded

# setup my_app to use tanstack db
mix phx.sync.tanstack_db.setup

Closes #83

@magnetised magnetised force-pushed the 83-igniter-task-to-add-frontend-code-for-tanstackdb branch 3 times, most recently from cfacb39 to 82d4baf Compare September 4, 2025 14:29
@thruflo
Copy link
Contributor

thruflo commented Sep 5, 2025

Just to flag

mix igniter.new my_app --install phoehix_sync --with phx.new --sync-mode embedded

Has a typo. Guessing this is just the PR description , not the code though.

Copy link
Contributor

@thruflo thruflo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. Slightly nervous that it's based on my burn auth code but perhaps it's as good as any as a starting point.

The main thing I'm thinking / aware of is that we have a TanStack Start based starter, and we're updating this for our new quickstart guide. I wonder if that could provide some externally maintained boilerplate that we could leverage here. I.e.: so the vendor frontend code in here doesn't get out of date over time.

I think this is great to start with though and it does the hard part of getting the Vite setup established.

The other thought I have is that the example app doesn't actually use a TanStack DB collection. It would perhaps be possible to generate with:

  • either a proper sync stack, so add a schema, expose via the router, sync into a collection, render that collection, implement the mutation handler and expose an ingest endpoint with that schema allowed in a writer pipeline; this would actually show the end to end machinery working, with a harmless / dummy table
  • or just with a localOnlyCollection -- so at least have a TanStack DB collection in the example front end code, with insert and delete operations working in the example React code in the index route. This could have a comment linking to the docs to migrate to an electric collection for actual Phoenix sync

I think without at least one actual collection being used we're missing a bit of a trick. There is obviously the auth collection in there which could be the one. But we're not rendering anything from is, as far as I can see? Maybe if we show the auth state in the template that could work but then we'd need to wire up to actual API auth which I think it larger scope than either of the two options above.


@spec short_doc() :: String.t()
def short_doc do
"Convert a Phoenix application to a Tanstack DB based frontend"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... to use a Vite + TanStack DB based frontend?


@spec example() :: String.t()
def example do
"mix phx.sync.tanstack_db"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no verb here. Like "phx.sync.convert_to_tanstack_db" or "phx.sync.gen_tanstack_db". I'm not sure what the right command is. Given it's a bit of a weird patchy thing, maybe just as is is fine but it's not the most descriptive command as is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. You've identified what's wrong with the task name. I'll have a think. Maybe the gen prefix is the right one. Maybe it's mix phx.sync.gen.tanstack_db which follows the patterns of the standard phx tasks like mix phx.gen.schema

@magnetised
Copy link
Contributor Author

either a proper sync stack, so add a schema, expose via the router, sync into a collection, render that collection, implement the mutation handler and expose an ingest endpoint with that schema allowed in a writer pipeline; this would actually show the end to end machinery working, with a harmless / dummy table

I thought of this but it's a lot of backend code, migrations, models, etc etc that no-one is going to want.

I think the right way to do this is to have another task that generates that example/bootstrap code from an existing schema.

or just with a localOnlyCollection -- so at least have a TanStack DB collection in the example front end code, with insert and delete operations working in the example React code in the index route. This could have a comment linking to the docs to migrate to an electric collection for actual Phoenix sync

That sounds much more useful for this stage.

@magnetised magnetised force-pushed the 83-igniter-task-to-add-frontend-code-for-tanstackdb branch from 82d4baf to 797174c Compare September 11, 2025 14:23
@magnetised
Copy link
Contributor Author

@thruflo have replaced the frontend code with a simple todo list (surprise!) backed by a localonlycollection and renamed the task to phx.sync.tanstack_db.setup with the idea that we can add other tasks under the phx.sync.tanstack_db.* namespace

@magnetised magnetised requested a review from thruflo September 11, 2025 14:42
Copy link
Contributor

@thruflo thruflo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome 👍

@magnetised magnetised force-pushed the 83-igniter-task-to-add-frontend-code-for-tanstackdb branch from 1e39c69 to fe73d07 Compare September 15, 2025 13:27
@magnetised magnetised merged commit f63bcd2 into main Sep 15, 2025
5 checks passed
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

Successfully merging this pull request may close these issues.

Igniter task to add frontend code for tanstack/db with vite

3 participants