Adding Persistent Toggle States for Research and Images

This update started as one of those tiny paper cuts that kept showing up while testing the auto writer. I would turn on internet research, enable image generation, refresh the page, and both toggles would jump back to their defaults. Not broken in the dramatic sense. Just annoying enough to interrupt the flow.

So I added persistent toggle states for two settings: internet research and images. Now the app remembers the last state the user picked, even after a page refresh or a new browser session. Small feature, big quality-of-life win.

This is the kind of thing that makes a tool feel more like something you actually use every day, not just a demo that resets itself every time you blink.

The problem I kept running into

The auto writer has a couple of optional modes. Internet research lets the writer pull in current context before generating an article. Images lets the workflow create or attach visuals during the writing process.

Both are useful, but not always needed.

• For fast drafts, I often leave internet research off.
• For articles that need fresh facts, I turn research on.
• For plain text posts, images stay off.
• For more visual posts, images go on.

The issue was that the UI treated these as temporary values. Refresh the app, and the choices disappeared. That meant I had to keep re-clicking the same switches while testing article generation. After the fifth or sixth time, the fix became obvious.

If a user makes a preference choice, the app should remember it unless there is a good reason not to.

The goal for this pass

I wanted a simple version first. Nothing fancy. No account-level settings. No database migration. No settings screen. Just make the toggle state stick on the same browser.

That made local storage the right place to start. It is fast, built into the browser, and perfect for lightweight interface preferences like this.

The feature needed to do four things:

• Load saved toggle values when the page opens.
• Use safe defaults if nothing has been saved yet.
• Update the UI instantly when a toggle changes.
• Save the new value so it survives a refresh.

That sounds basic, but these small state features can get messy if the app reads from storage too early, writes too often, or mixes up boolean values with strings.

The settings I decided to persist

I kept the first version focused on two toggles. These are the ones that directly affect cost, speed, and output style, so they deserve to be remembered.

Setting	Saved key	Default	Why it matters
Internet research	autoWriterInternetResearch	false	Keeps quick drafts fast unless the user chooses live research.
Images	autoWriterImages	false	Prevents surprise image generation and keeps the workflow predictable.

I used separate keys instead of one combined settings object at first. That made the implementation easier to inspect during testing. Open dev tools, check local storage, and the values are right there.

Later, I may move these into a single versioned settings object. Something like autoWriterSettings with nested values. For now, separate keys were easier, and easy was the right call.

First pass: read from local storage

The first thing I added was a small helper for reading saved booleans. Local storage stores everything as strings, so saving true gives you "true", not a real boolean.

That distinction matters. If you treat the string "false" as a boolean, it can behave like truthy text instead of false. That is a sneaky bug and it makes toggles look haunted.

The helper logic was plain:

• Look up the saved value by key.
• If the value is "true", return true.
• If the value is "false", return false.
• If nothing is saved, return the default.

This kept the app from guessing. It either found a known value or fell back to the default.

Second pass: connect it to state

Once the helper was in place, I wired the toggles into the component state. The key detail was setting the initial state from local storage instead of hardcoding everything inside the component.

For example, internet research used to start as false every time. Now it starts by asking, “Do we already have a saved preference?” If yes, it uses that. If not, it starts false.

Same move for images.

This gave me the first small win. I refreshed the page after turning research on, and the toggle stayed on. Nice. One of those tiny moments where the app suddenly feels less flimsy.

Third pass: save changes when the user clicks

Reading the saved value only solves half the problem. The app also needs to save the new state whenever a user flips a toggle.

I handled that inside the toggle change function. When the user clicks the research switch, the app updates the state and writes the same value into local storage. Same thing for the image switch.

The shape was simple:

• User clicks toggle.
• App calculates the next value.
• State updates immediately so the UI feels responsive.
• Local storage gets the new value as a string.

I prefer saving right inside the handler for small settings like this. It keeps the cause and effect close together. Click toggle, save preference. No mystery.

The first thing that broke

The first bug was exactly what I expected: one toggle looked correct in storage but not in the UI after refresh.

The cause was a mismatch between the key used to save the value and the key used to read it. One had a slightly different name. Classic tiny typo.

This is why I like readable local storage keys during early builds. If the saved key says autoWriterImages, the reader should use autoWriterImages. Boring names are good names here.

I fixed the mismatch and added the keys as constants so I would not keep typing raw strings in different parts of the file.

Any time the same storage key appears in more than one place, pull it into a constant. Future you will thank current you.

The second thing that needed cleanup

The next issue was less broken and more messy. The toggle handlers were doing nearly the same thing twice. One function for research, one function for images, same pattern.

I left it duplicated for a few minutes because I wanted to prove the feature worked before cleaning it up. That is a common rhythm in this build. Make it work, then make it less embarrassing.

After testing both toggles, I pulled the save behavior into a small reusable function. It took a key and a boolean value, then saved the string version into local storage.

That gave me cleaner handlers without making the code too abstract. I did not want a whole settings manager yet. Just a tiny helper that removed copy-paste risk.

The behavior I wanted in the UI

A persistent setting should feel quiet. The user should not have to think about how it works. They click the toggle, move on, and the app remembers.

I tested the flow a few ways:

• Turn research on, refresh, confirm it stays on.
• Turn research off, refresh, confirm it stays off.
• Turn images on, refresh, confirm it stays on.
• Turn images off, refresh, confirm it stays off.
• Close the tab, open the app again, confirm both values still load.
• Clear local storage, confirm both toggles return to their defaults.

That last test matters because defaults are part of the feature. If storage is empty, corrupted, or cleared, the app should still behave normally.

Why the defaults are off

I set both toggles to off by default on purpose.

Internet research can slow down generation, and depending on how the backend is wired, it may also use extra API calls. Image generation can do the same. Those are user-controlled add-ons, not assumptions the app should make automatically.

Defaulting to off keeps the first run predictable. If someone wants a richer article with research and images, they can turn those modes on once and the app will remember from there.

The build sequence

Here is the actual order I followed while adding this. Nothing glamorous, just steady progress.

1. Found the existing toggle state inside the auto writer UI.
2. Added constants for the local storage keys.
3. Created a boolean reader that safely converts saved strings back into real booleans.
4. Changed the initial toggle state to read from storage first.
5. Updated each toggle handler so it saves the new value after a click.
6. Refreshed the app repeatedly and checked the browser storage panel.
7. Fixed a key naming mismatch.
8. Moved repeated save logic into a small helper.
9. Tested empty storage to make sure defaults still worked.

This is the kind of update that looks tiny from the outside, but it touches the feeling of the product. A setting that sticks tells the user, “I heard you.”

A note on local storage versus database settings

Local storage is not the final answer for every setting. It is tied to the browser, so if the same user logs in from another device, these preferences will not follow them.

For this stage, that is fine. The app is still moving quickly, and these toggles are interface preferences rather than account data. I would rather ship the useful version now than pause everything to build a full settings system too early.

When user accounts become a bigger part of the tool, this can graduate into saved profile settings. The frontend can still use local storage for instant loading, then sync with the backend once the user is authenticated.

What I would improve next

This version works, but a few improvements are already on the list.

• Add a small settings utility file so storage helpers are not tied to one component.
• Group all auto writer preferences into one versioned object.
• Add a reset button for users who want to return to defaults.
• Sync preferences to user accounts later.
• Show subtle helper text so users know these options will be remembered.

The versioned settings object is probably the next real cleanup. Something like { version: 1, internetResearch: false, images: true } would make future migrations easier if the settings list grows.

For now, the current setup is good enough and easy to reason about. That balance matters when building fast.

Small UX details that made it feel better

I also spent a little time watching how the toggles felt during use. Not the code, just the behavior.

The toggle should update immediately. If the UI waits for anything before flipping, it feels laggy. Since local storage writes are instant for this kind of small value, there is no reason to delay the visual change.

I also avoided showing a toast every time a toggle changed. That would be noisy. Persistent settings should not celebrate themselves on every click. The proof is in the next refresh.

The best version of this feature is almost invisible.

Testing notes from the build

Testing this was mostly manual, and that was fine for the first pass. I kept the browser dev tools open on the Application tab, then watched local storage while clicking each toggle.

A few things I checked:

• The value changed when the toggle changed.
• The value was stored as "true" or "false".
• The UI matched the saved value after refresh.
• The default loaded correctly after deleting the saved key.
• Both toggles worked independently.

That last one caught another small issue. At one point, I had copied the save function and accidentally pointed both toggles at the same key. Turning images on also changed the research preference. Easy fix, but a good reminder to test settings side by side, not one at a time.

What this taught me

This was a simple feature, but it reinforced a pattern I keep coming back to while building this auto writer: save user intent as close to the action as possible.

If someone picks a writing mode, preserve it. If they choose a format, remember it. If they disable something that costs time or credits, do not turn it back on behind their back.

These tiny memory features stack up. One remembered toggle does not transform the product by itself, but ten remembered choices make the whole tool feel calmer and more personal.

Current state

The auto writer now remembers the internet research and image toggles across refreshes. The defaults are safe, the storage keys are readable, and the behavior matches what I want as a user.

Not a massive feature. Still a good one.

Next I’ll probably move these settings into a shared preferences helper, because I can already see more toggles coming. Tone controls, article length, formatting options, maybe source depth. Once those arrive, this little persistence pattern will be ready to carry more weight.