React apps
How to build a multi-page React app with Div-idy
A Div-idy project can contain a home page and additional React pages for separate parts of the user journey. Describe the page list, links, and data relationships in your prompt, or add pages in the project studio. Each page compiles independently, while Div-idy’s navigation connects the project across previews and published URLs.
Plan pages around visitor tasks
Give each page a clear purpose. A workshop site might have Home for its introduction, Workshops for available sessions, and Inquiry for submitting a request. Use short, descriptive page names and specify where primary buttons should lead.
A multi-page app is useful when visitors have distinct tasks or when separate topics deserve their own URL. Tabs, accordions, and filtered views can remain within one React page when a separate route adds little value.
Describe navigation and shared information together
Build a three-page workshop app: Home, Workshops, and Inquiry. Use the same header and mobile menu on every page. Home links to Workshops. Workshops shows the owner’s published workshop records. Inquiry lets visitors choose a workshop and submit a request to the project owner. Use the same workshop IDs and titles throughout. Give each page a descriptive title and summary.
State whether shared information is device-local, owner-managed content, or a visitor submission. Separate pages should agree on field names and storage keys.
Add and refine pages in the project studio
- Open Pages in the project studio and review the existing page list.
- Use Add page when you need another route, then name and save it.
- Open that page for AI editing and describe its purpose and connection to the existing app.
- Preview the home page and follow the whole journey through the new page.
Specify which existing layout, colors, terminology, and interactions should carry across. Page-specific edits should name their intended scope.
How do links work across hosting locations?
React pages use the built-in navigation API with canonical page slugs such as home and workshops. The runtime resolves the appropriate preview or published route. Generated links should not hardcode project IDs, preview paths, or a particular domain.
External links and in-page section anchors serve different purposes and can remain ordinary links. Test the logo, main navigation, calls to action, and return links.
Review the complete published journey
Check every page on a phone-sized screen, including direct entry to child pages. Confirm that published content appears and that owner-only management stays in the private preview. Publish the pages visitors need for the complete journey; a link to an unpublished page does not make that page public.