feat:drizzle

[phonzammi]

@magne4000
Let me try to integrate Drizzle ORM into Bati. Please help me resolve this feature.

FYI, I've added ERROR_DRIZZLE_R_SERVER to the rules. Drizzle ORM is primarily designed to be used on the server side.

1. Frameworks + Servers + drizzle :

• boilerplates
• e2e test

2. Frameworks + Servers + RPCs + drizzle :

• boilerplates
• e2e test

[magne4000]

I would add a README with:

• references to the added package.json scripts (drizzle:generate, drizzle:...)
• links to the documentation and getting started pages

The other cool thing would be to adapt the default TODO examples, let me explain.
Currently, TODO examples for telefunc and trpc are using boilerplates/shared-db as a "Data store".
My idea was, if drizzle is selected, instead of using boilerplates/shared-db, use boilerplates/drizzle.
This requires that we use those 2 in a same manner (with same TS interfaces) to simplify their usage (so we'll perhaps need to adapt boilerplates/shared-db).

What do you think?

[phonzammi]

I would add a README with:

• references to the added package.json scripts (drizzle:generate, drizzle:...)
• links to the documentation and getting started pages

Sure, I'll do it later. There are more things I'll need to add.

The other cool thing would be to adapt the default TODO examples

I'm planning to add {react|solid|vue}-drizzle. We also could use existing {react|solid|vue}-{telefunc|trpc} for telefunc|trpc with drizzle, we only need to add condition if BATI.has('drizzle') then we use db.
I also have tested all of these use cases I can think of.

we'll perhaps need to adapt boilerplates/shared-db

We don't need to do db.select() at https://github.com/batijs/bati/blob/main/boilerplates/shared-db/files/database/todoItems.ts, we can do it in +data.ts.

What do you think ?

[magne4000]

We don't need to do db.select() at main/boilerplates/shared-db/files/database/todoItems.ts, we can do it in +data.ts.

I agree, let's do that 👍

[magne4000]

You can see that a things have been moved around a lot 😅

Now, Todo is always present, with a default "database" using lowdb if none was selected.
Also, trpc, telefunc, and rest todo endpoints have been streamlined to look the same.
With those 2 changes, I have been able to get rid of many superfluous boilerplate folders.

One last thing remains: proper E2E tests. All db + data fetching tests have been moved to FRAMEWORK+SERVER+DATA.spec.ts test file, but we can do a lot better.

On last few Bati's updates, I added support for happy-dom environment in tests, which allows us to simulate real user interactions in the UI. You can take a look at FRAMEWORK+SERVER+AUTH.dom.spec.ts file to get an idea of how to use it, and also check happy-dom documentation.

What I would to do is to remove the testMatch block in FRAMEWORK+SERVER+DATA.spec.ts and replace it by a new FRAMEWORK+SERVER+DATA.dom.spec.ts file.
In this file, we should test the following things:

• User opens /todo for the first time and sees our 2 items
• User clicks on Add to-do, and we check that the 3rd item appears in the UI
• User refreshes the page, and we check we have 3 items
• bonus: I would also like to test the case where we have a network error, but I haven't check if that's possible yet

@phonzammi Can I let you finish implementing those tests?

I know there has been a lot of changes, so do not hesitate to ask me anything if something isn't clear.

PS: we might need to extend tests timeouts quite a bit because files are getting quite big

[phonzammi]

@magne4000, Thank you so much, your changes are awesome. I really appreciate that.

I'm sorry I couldn't resolve all of your reviews, and I apologize for the number of commits this pull request required from me. 😄. I'm okay if you need to squash them, (FYI, I've never squashed commits before.)

Can I let you finish implementing those tests?

Of course, I would like to try it. Thanks for letting me implement it. And let me know if it took too long for me to implement it.

[magne4000]

As discussed on Discord, we are currently blocked by happy-dom not working for complex E2E tests using React, Solid and API calls. We'll have the same limitations with JSDOM, so the best course of action would be to add support for Playwright in our test suite (to be done in a subsequent PR)