u/Particular_Luck80

I'm building Flowy, a health tracking app, and the current local-reminder code is split into two parts.

The planner is a pure function. It takes settings and dates and returns identifiers, copy, dates, hours, and repeat flags. A thin Expo adapter asks for permission, cancels the old schedule, and schedules the new plan.

That makes the planner easy to preview and test. It also makes the risky part clearer: cancel-all plus a partial scheduling failure can leave only part of the new plan active.

The useful lesson wasn't just "pure functions test better." Separating the side effects showed exactly where recovery still needs work.

In an Expo React Native app, I have an optional HealthKit adapter. Android returns a no-op adapter immediately. On iOS, the request and read methods dynamically import the native package inside try/catch, so a missing native module becomes false or an empty array instead of crashing the app at startup.

The upside is a safe manual fallback. The downside is that a packaging mistake can look exactly like a user declining access or HealthKit being unavailable unless I surface a separate diagnostic.

Would you keep the dynamic import boundary, or fail loudly in development and only fall back in release builds?

I’m building Flowy, a cycle-health app. I recently replaced the native iOS project with an Expo and React Native app.

The screens were the easy part. The risky bits are session restoration, onboarding drafts, owner-scoped day-log caches, notification planning, HealthKit being unavailable, and retrying a write without duplicating it.

I kept those decisions in small TypeScript stores and route functions, with tests around routing, auth, day-log retries, notifications, and HealthKit fallback before polishing the UI.

No link here. I’m looking for engineering feedback: if you’ve done a mobile rewrite, which behavior broke after the happy path looked finished?

I'm using Expo ImagePicker and Supabase Storage for avatars in a React Native app.

The current path is {userID}/avatar/{timestamp}.jpg, then I insert a media row. Uploading with upsert: true looks like replacement, but because every path is new, old files remain unless I delete them separately.

I'm deciding between:

- one stable avatar.jpg key with cache-busting metadata

- immutable versioned keys, update the pointer, then delete the previous object after the database write succeeds

- keep a short version history and clean it in the background

The stable key is simpler, but caches can show the old photo. Versioned keys are clearer, but cleanup becomes part of the transaction. Which pattern has been less fragile for you on mobile?

I'm working through local reminder rescheduling in a React Native app. The reminder dates come from settings the user can edit later.

Right now the flow is:

- calculate the full next schedule

- cancel every scheduled notification

- recreate each one with a stable identifier

It avoids orphaned reminders after the source date changes. But if scheduling fails halfway through, the user can end up with only part of the new set.

Would you keep the simple replace-all model and add recovery, or diff old and new schedules by identifier? I'm using Expo Notifications.

I’m working through an offline queue edge case in React Native.

A write is saved locally with an expected server version and reset epoch. If the request times out, retrying with the same mutation ID is safe. But if the user resets their server data before the queue flushes, that old write must not quietly come back.

My current rule is:

- keep the same mutation ID after a lost response

- compare the reset epoch on every retry

- reject queued work from an older epoch

- keep local intent over stale reads only while the queue item is still valid

The tricky part is UX. Dropping the stale write is safer, but hiding it feels wrong. Would you show a persistent “couldn’t sync” item, a one-time alert, or a recoverable draft?

A pattern worth checking: a screen waits for an animation-completion callback before it updates state or enables the next action. It works until iOS Reduce Motion skips or changes that animation.

I now treat motion as presentation only. The state change happens independently, then the animation reflects it. If reduced motion is enabled, movement can disappear without changing navigation, loading, focus, or button availability.

For React Native, I’m testing both the normal and reduced-motion branches around:

- navigation transitions

- delayed mounts

- sheets and modals

- focus after validation

- callbacks that previously fired at animation end

I’m curious how others automate this. Do you mock AccessibilityInfo.isReduceMotionEnabled in unit tests, cover it in Detox, or both?

I added a calendar export to a period calculator and nearly missed a semantics problem: moving an estimate into someone’s calendar can make it look more certain than it was inside the app.

The export is generated locally in the browser. Each predicted period becomes an all-day event with the summary "Estimated period (Flowy)". The event is also marked STATUS:TENTATIVE and TRANSP:TRANSPARENT, so it remains visibly provisional and does not block the person’s availability.

The description repeats the boundary: it is a tentative planning estimate, not medical advice or birth control. The page also warns that the user’s chosen calendar provider may sync those events after import. That handoff matters even though Flowy never receives the dates used by the calculator.

I added a test that checks the event count, start and end dates, and tentative status. The date arithmetic uses UTC-only calendar dates so an import cannot quietly move an event to the previous day because of timezone or daylight-saving behavior.

The broader lesson for me is that uncertainty has to survive every export. A careful label in your UI is not enough if the CSV, PDF, webhook, or calendar file turns the same value into a fact.

Project context: https://flowyhealth.com/tools/period-calculator

Where have you seen an export format accidentally make uncertain data look authoritative?

I found JAIPilot on Hacker News newest today. It wraps Codex or Claude Code with a local control plane for Java tests and cleanup, but the useful idea is broader than Java.

The workflow separates generation from admission.

Every run starts with a clean build, snapshots the live source, creates an isolated workspace, and records the exact targets. The agent edits only that workspace. Validation then enforces the allowed scope, runs another clean build, checks that changed tests actually executed from fresh test reports, and can use coverage and mutation evidence.

The drift checks are the detail I like. Validation snapshots the candidate and rejects source written by build steps. Apply requires the candidate to match the immediately validated snapshot, while the live source must still match its original snapshot. Only allowlisted files are written back. Discard leaves the real tree unchanged.

That suggests a practical boundary for coding agents: let the model propose changes in isolation, but make admission to the real repository a deterministic step based on scope, build output, and fresh evidence.

There is more ceremony. But the failure mode becomes "candidate rejected before apply" instead of "agent edited an unrelated file and we noticed later."

Source: https://github.com/JAIPilot/jaipilot/blob/main/docs/how-it-works.md

What evidence do you require before an agent-generated candidate can enter the real worktree?

I’m building a page-based document editor using Tiptap/ProseMirror, and performance starts falling apart once a document reaches roughly 60 pages. Typing latency rises, selection/cursor behavior becomes less reliable, pagination/reflow gets expensive, and the UI can become generally sluggish.

Google Docs, by comparison, seems able to handle documents with 100, 200, 300, 400, or even 500+ pages much more gracefully. I realize Google’s exact implementation is proprietary and has evolved over time, but I’d love to understand the architectural techniques that make this scale possible—and which of them can realistically be applied to a ProseMirror-based editor.

I’m especially interested in detailed answers from anyone who has built or profiled a large web-based document editor.

Questions I’m trying to answer:

1. Rendering and virtualization

- Does Google Docs keep the entire document represented in the DOM, or does it render only the visible pages plus an overscan window?

- Are off-screen pages removed, replaced with height-preserving placeholders, or rendered using canvas/another custom rendering layer?

- How can an editor virtualize pages without breaking native text selection, IME composition, accessibility, browser find, copy/paste, spellcheck, and screen readers?

- In ProseMirror, can distant nodes be safely replaced by lightweight decorations/placeholders while preserving positions, mappings, selections, and transaction correctness?

- Is it better to virtualize by page, block, viewport range, or document section?

2. Pagination and layout

- How is pagination normally implemented without measuring every node after every transaction?

- Is layout computed incrementally from the changed block forward until page boundaries become stable again?

- What data structures are useful for caching block heights, page break positions, line measurements, and cumulative offsets?

- How do mature editors handle changes near page 1 that could theoretically repaginate hundreds of later pages?

- Are explicit “page” nodes usually a mistake? Would it be better to keep one semantic document model and calculate pages as a separate layout projection?

- How should hard page breaks, tables spanning pages, images, footnotes, headers/footers, margins, and keep-with-next rules be modeled?

3. ProseMirror/Tiptap-specific bottlenecks

- Does ProseMirror fundamentally expect one mounted EditorView for the full document, or can a large document be split across multiple views while still behaving like one editor?

- Would one EditorView per page create more problems than it solves—for example cross-page selections, history, input rules, decorations, collaboration, and position mapping?

- Which operations tend to become O(document size): DOM reconciliation, decoration mapping, plugin apply methods, NodeView updates, transaction filtering, serialization, or schema traversal?

- How can I identify plugins that scan the entire document on every keystroke?

- Are there proven patterns for keeping a single canonical ProseMirror document while rendering only a bounded window?

- At what point is ProseMirror’s DOM-based model the wrong abstraction for a Google-Docs-scale editor?

4. State, and persistence

- Does a large editor typically keep the whole logical document client-side, or load/chunk it by section?

- How are undo/redo changes kept efficient when the document contains hundreds of pages?

- How should comments, suggestions, presence cursors, and remote selections be indexed so they don’t require full-document scans?

5. Browser and rendering techniques

- Which parts are commonly moved to Web Workers: pagination, text measurement, parsing, collaboration, spellcheck, indexing, or serialization?

- Since workers cannot directly measure DOM layout, how do production editors divide layout work between a worker and the main thread?

- Are ResizeObserver/IntersectionObserver enough, or do they introduce their own performance problems at hundreds of pages?

- How important are CSS containment, content-visibility, requestAnimationFrame batching, idle callbacks, and avoiding synchronous layout reads?

- If canvas is used for text, how are cursor placement, selection, IME, accessibility, and copy/paste implemented?

6. Benchmarks and debugging

- What should I measure first: input latency, long tasks, transaction time, ProseMirror view updates, forced reflow, DOM node count, heap size, GC pauses, or layout/paint time?

- Are there useful rules of thumb for maximum mounted DOM nodes/pages?

- What synthetic test documents best expose the real bottleneck: plain paragraphs, large tables, many inline marks, comments, images, or collaborative decorations?

- Are there open-source editors, talks, papers, or codebases that demonstrate large-document pagination well?

I’m not looking for Google’s proprietary source code. I’m trying to learn the system-design principles behind a responsive, paginated web editor.

If you have built something similar, I’d be very interested in:

- your document/page count and approximate node count;

- which bottleneck appeared first;

- the architecture you settled on;

- what you tried that did not work;

- whether virtualization actually helped;

- any relevant ProseMirror plugins, examples, benchmarks, or profiling techniques.

Even a high-level breakdown of how you would architect this from scratch would be extremely helpful.

Pitching a very big client tomorrow who wants to build their business from scratch and scale with us.

They need:
- branding and logo designing
- Website designing and development ecom
- packaging and labelling
- handling their paid ads accounts on instagram, meta, google, tiktock, koupon, etc
- social media management
- and content creation.

Not a typical client as he already is showing good interest in my DM agency!

What should my proposal or quotation document need to have?