feat: add disclosure for settings

[seaerchin]

TL;DR

This PR introduces a folder settings modal in the folder page.

What changed?

• Imported necessary components like Modal, Input, FormControl, etc.
• Added folder settings modal state management using useDisclosure hook.
• Created a new FolderSettingsModal component for folder settings.
• Utilized the useZodForm for form handling and validation.
• Implemented the mutation to save folder settings changes to the database.
• Updated schema and router to support editing folder's title and permalink.

How to test?

1. Navigate to the folder page.
2. Click on the Folder settings button.
3. Update the title and permalink in the modal.
4. Click Save changes and verify if the changes are reflected.

Why make this change?

This change adds the ability to edit the folder title and permalink directly from the folder page, enhancing the user experience by providing a straightforward way to manage folder settings.

---

Screen.Recording.2024-08-07.at.5.47.04.PM.mov

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
isomer-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 12, 2024 4:06pm

[seaerchin]

• feat: add disclosure for settings #451 👈
• feat: add folder views #437
• feat: add new site side nav #436
• chore: shift page.list to resource #418
• feat: add base modal ui #417
• feat(move): move pages functionality #403
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @seaerchin and the rest of your teammates on Graphite

[karrui]

should this continue to be int? since schema is still an int.
folderId can be string because folder's id is bigint.

[seaerchin]

wa actually i changed it to string here - i agree with the reasoning you gave that the bigint is just to autoincrement automatically for id, but on the frontend we can just treat as a string since we'll never interact with it.

i think changing to string here is ok - i'll have a PR to change number -> string later on wdyt?

[karrui]

we should refrain from all the casting and transformations imo. easy to desync or lose reasoning on why the types are the way they are. as discussed offline, since we do not actually do any arithmetic on the resource ids, we technically can keep them in their expected types: siteId: int, resourceId: string. Server should be able to pass them to the query without any transformations too

[seaerchin]

i agree. how do we feel about a PR later on to tidy these types since they are unlikely to change? i want to do a 1 shot change rather than in phases so that post change, it's easier to reference and take code

[karrui]

lgtm after you fix ci

[seaerchin]

Merge activity

• Aug 12, 11:51 AM EDT: @seaerchin started a stack merge that includes this pull request via Graphite.
• Aug 12, 12:01 PM EDT: Graphite rebased this pull request as part of a merge.
• Aug 12, 12:07 PM EDT: @seaerchin merged this pull request with Graphite.