I was prototyping a screen that loads a list of wallpapers, and the preview opened without a hitch. Only the list itself stayed empty. No red error screen, nothing to read, nothing to point at.
So I sent nearly the same message three times: "The list doesn't show. Please fix it." Each time the reply said it had been fixed, and each time the screen looked the same. Looking back, I was asking the AI, and myself, to repair something neither of us could see.
What I'd like to say first is that a problem with no error screen often isn't "broken" so much as "not visible yet." And the tool that makes it visible is already inside your project.
The Logs panel is where the app says what it did
Open More → Code in a Rork project and you get the file tree and the source. Underneath sits a panel called Logs. It lists what your app printed while it ran in the preview, in real time.
Each line starts with one of [log], [info], [warn], [error] or [debug]. Scroll up and older lines load as you go, and the chevron on the right collapses the panel. According to Rork's docs, the Code view is readable on every plan and only hand-editing needs a paid one (Read the code and read the logs). Reading logs, in other words, works on the free plan too.
If the panel says "No logs yet. Logs from your app will appear here," nothing is wrong. Use the preview — tap around — so the app has something to print.
The cause is usually one of three places
When a list comes up empty, I sort the possibilities like this.
| Stage | What is happening | What to check in the logs |
|---|---|---|
| 1. Never fetched | The code that loads the data never runs | Is there a line for the start of loading? |
| 2. Fetched, but empty | The request succeeds and returns 0 items | The request status and the item count |
| 3. Fetched, but not drawn | Items exist, but a display condition hides them | The count right before it reaches the screen |
If you only say "please fix it," the AI doesn't know which of the three it's dealing with, so it rewrites the most likely spot. Sometimes that works. When it doesn't, you collect "fixes" that fixed nothing.
Ask it to show, not to fix
So before asking for a fix, I ask only for logging. Rork's docs even use this pattern — ask for logs first when something misbehaves without an error dialog. Here's the wording I use.
On the list screen, add temporary log lines around the code that fetches data:
- one line when loading starts
- one line when loading ends, with the request status and the number of items returned
- one line just before the list is drawn, with the number of items it will show
Don't change any behavior. Only add the logs."Only add the logs" is the part that matters. Without a limit, the AI will helpfully touch the surrounding code, and the evidence moves with it.
What the agent adds will look roughly like this. The exact shape depends on your project's language and structure, so treat it as something to read, not to paste.
// Example: log before/after loading and right before handing data to the screen
console.log("[wallpapers] fetch start");
const res = await fetch(url);
console.log("[wallpapers] status", res.status); // request status
const items = await res.json();
console.log("[wallpapers] received", items.length); // items returned
const visible = items.filter((i) => i.published);
console.log("[wallpapers] visible", visible.length); // items left after the display conditionEach stage gets its own line on purpose. If the last two read received 24 and visible 0, the request is fine and a display condition is throwing everything away. (The numbers are an example.)
Read the lines, then pick the next move
Reproduce the problem in the preview and look at Logs.
- No
fetch start: stage 1. The loading code is never called received 0: stage 2. Suspect where the data comes from — the URL, authentication, or the data on the server — rather than the screenreceivedpositive butvisible 0: stage 3. Look at the filter- An
[error]line: that line is the first thing worth pasting
Once you know which line is the answer, paste just that line. Rork's docs also recommend grounding the model with real inputs. In my experience, one relevant line plus the scope you want touched works better than the whole log.
Logs show:
[wallpapers] received 24
[wallpapers] visible 0
Only review the filter applied before the data reaches the screen. Don't change other files.If you need to dig deeper into the request itself, Debugging network and API request failures in Rork may help.
Check for keys before you paste
One habit before pasting: skim the log for anything that looks like a token or API key. If you print a response or request as-is, those can ride along.
Mask them before sending. And whether keys are hard-coded in your project at all is something I wrote a separate check for: a 40-line script to check once whether Rork's code has keys written into it.
If there is a red error, press that first
Everything above is for the case with no error. If the preview does show a red error, try Fix with Rork on the error itself before reading logs — that's what Rork's docs suggest for visible errors.
And when your "fixes" keep piling up without changing anything, going back one version is sometimes quicker. I sorted out how to choose between the options in Undo, Revert, or Edit message in Rork.
One line to keep
Make it visible before you ask for a fix.
That list turned out to be a display condition I'd overlooked. The moment received and visible showed up side by side in Logs, those three "please fix it" messages made sense at last, and my shoulders came down.
Next time a screen comes up empty, try sending just one sentence before any fix request: "Log the number of items fetched and the number about to be shown." That's where I start these days, too.