Setting Up & Using Claude Code with Wappler: Week 1 Thoughts

For the past 1.5 years, I've been using some form of google's AI to help move my development along. Google AI Studio served me well, but the copy/paste/test routine eventually got old. I decided to switch to Claude Code (Pro subscription) recently and wanted to share a few getting started tips and what I've seen Claude Code can do well with Wappler.

First, I'd suggest installing the terminal version of Claude Code. Then add the extension in your IDE (my preference is VSCode). Next, you'll want to run /init from the root of your Wappler project so Claude Code can learn about your project, but don't execute this command just yet. There are many files in your Wappler project folder and Claude Code doesn't need to scan them (uses up unneeded context and tokens).

I started by telling Claude Code that I wanted to run the /init command but there were many folders and files that were not necessary to be scanned. Claude Code said, "Sure, I'll quickly scan your project and create a .claudeignore file." It ended up looking like this:

# Wappler IDE and framework
.wappler/
lib/
public/dmxAppConnect/
public/bootstrap/
extensions/

# Deployment and infrastructure
app/targets/
app/providers/
app/.ssh/
app/seeds/
app/migrations/
certs/
db/
logs/

# OS metadata
.DS_Store

# Dependencies
node_modules/

Now I can run /init to teach Claude Code about my Wappler project without wasting the context window and my money. Claude will then create a CLAUDE.md file in the project's root folder and it will use this every time you start a new session. CLAUDE.md gives Claude context about your project and other useful information (see the claude docs about this file). This file should remain lean and only contain info that Claude can't figure out on its own. For example, I just added HTTP status code mappings to Wappler events inside CLAUDE.md because it incorrectly used a dmx-on:error with a 400 response when writing a new API. A 400 response throws an "Invalid" response, not an error response so CLAUDE.md needed to be updated.

What was really cool is that I started a new chat, and told claude we needed to update the CLAUDE.md file with the screenshot I took from the forum:

Claude scanned the screenshot and updated the CLAUDE.md file with the following section:

#### Server Connect Event Triggers

Server Connect components (`<dmx-serverconnect>`) trigger different events based on HTTP status codes returned from server actions:

- **success** (`dmx-on:success`) — Status code < 400
- **invalid** (`dmx-on:invalid`) — Status code 400
- **unauthorized** (`dmx-on:unauthorized`) — Status code 401
- **forbidden** (`dmx-on:forbidden`) — Status code 403
- **error** (`dmx-on:error`) — Status codes 402, > 403, or parse errors
- **start** (`dmx-on:start`) — Triggers when request is about to start
- **abort** (`dmx-on:abort`) — Triggers when request was aborted
- **done** (`dmx-on:done`) — Always triggers when request is finished (regardless of success/failure)
- **upload/download** — Progress events for file transfers

Now Claude can correctly map form submit events and server connect responses so page notifications work as expected.

FYI: Chats are not saved unless you ask Claude to save the conversation. So if you want to have a record of a conversation make sure to tell Claude to save it.

It's only been a few days since I've used Claude Code with Wappler, but it is certainly more competent than Google AI Studio. Because it can directly edit the files within the project, it's also faster to build with than the copy/paste/test routine using AI Studio. It has no problem integrating JS with Wappler's DOM, creating nested repeats, using dmx.parse() to set and update variables from within JS. It even knows about using dmx.app.data within the console to help with debugging. This morning, I allowed it to modify an existing API endpoint and it passed my testing on the first try.

All Claude Code changes to files within my project have used Sonnet 4.5 rather than Opus 4.5/4.6. I ran out of tokens one day using Opus 4.5 and I wasn't using any MCP's or subagents. I expect Opus 4.6 to be even heavier on the token usage. Sonnet 4.5 has worked very well so far and gives me a full day of working on features/bug fixes without being capped and having to wait a few hours before my usage resets (my Pro subscription has limits of course).

I would then highly recommend Claude Code with the Sonnet model for daily Wappler development. I see Claude Code getting even better at Wappler over time as my CLAUDE.md file contains those important bits of info that AI may usually stumble over with Wappler again, and again, and again.

My next task with Claude Code is to take a set of UI designs I made within Google Stitch and completely update the logged in user UI. I'm looking forward to it rather than dreading it.