DEV Community: Suyash Vashishtha

I Shipped an Play Store App That Updates Itself, Because There's Nothing in It to Update

Suyash Vashishtha — Tue, 08 Sep 2026 07:53:00 +0000

com.myvitals.app, installed from the Play Store, icon and splash screen and everything, has almost no native UI. Open the source: a splash screen, an error screen, one WebView pointed at https://myvitals.co.in. That's the app.

export const WEBVIEW_URL = 'https://myvitals.co.in';

That string is functionally the entire product. Ship a fix to the web frontend — a normal deploy — and every installed app gets it next open. No review queue, no staged rollout, no "update available" nag. The native shell itself changes maybe a few times a year (a permission, an icon); everything users experience as "the app" ships at web speed, to 100% of installs, at once.

The trade

No true offline bundle — if the WebView can't reach the internet on first paint, there's nothing local to fall back to. (The actual offline story lives entirely on the web side — service worker + IndexedDB, covered separately.)
You inherit WebView quirks — env(safe-area-inset-*) often resolves to 0 even with viewport-fit=cover set. Fix: stack a fixed minimum padding on top of the CSS value instead of trusting it alone.

"Finished loading" ≠ "actually works"

onLoadEnd means "navigation finished," not "a human would call this working" — for a React SPA, the shell can be blank while JS boots. So there's a second signal: a 15-second timer, and if still loading when it fires, that's a failure regardless of what the WebView reported.

The real gotcha: onLoadEnd fires after onError too — it's "did-finish," not success-only. Wire it naively and a failed load flashes an error screen then un-fails itself a moment later. Fix is one ref, set the instant an error fires, checked before allowing success to override it.

Retry doesn't call .reload() — it bumps a key prop and lets React fully remount the WebView, after checking real connectivity first. A stale WebView instance can wedge itself into states a soft reload won't clear.

Bridging the back button

Android's hardware back button should navigate the website's own history. Track canGoBack from WebView nav state; on back-press, call goBack() if there's history — and explicitly do nothing (let the OS exit the app) if there isn't. Swallowing back-press unconditionally traps users on a screen with a dead back button, which is worse than not intercepting it.

Making a website stop feeling clickable

Injected JS disables text selection and long-press callouts globally (except real inputs), suppresses the copy/share/lookup context menu, kills link previews, and turns off bounce/overscroll. Same instinct on the web side via -webkit-tap-highlight-color: transparent and overscroll-behavior-y: none — belt and suspenders across the native/web boundary.

Camera permission for a plain HTML input

The upload flow is a bare <input type="file"> — the web app has no idea it's in a WebView. But camera capture from a web file picker needs an OS permission that behaves inconsistently if only requested lazily mid-flow. So the shell proactively requests camera/photo permissions once the page loads, ahead of the user ever tapping upload.

The one screen the theming audit never reached

Small confession: the error screen's retry button is a hardcoded #2E7D5B green. Brand teal everywhere else is #0d9488. Not the same color — and this is the one screen a 21-page design consolidation pass never touched, because it's native code that only renders when something's already gone wrong.

👉 Try MyVitals now — same app, same day, web or home screen icon.

The Month My AI Pipeline Failed 100% of the Time and Every Log Said "Success"

Suyash Vashishtha — Mon, 07 Sep 2026 07:51:00 +0000

MyVitals extracts lab values with one LLM call, then reconciles raw names against a shared dictionary — exact match, fuzzy match, then an LLM call for the leftovers. If that call fails outright, the pipeline doesn't fail the upload — it degrades: unmatched metrics auto-create a new dictionary entry instead of finding the right one. Good design, on its own.

Here's the problem: an env var meant for the OCR endpoint got set on the variable that goes to Chat Completions instead. Every metric-matching call, for about a month, hit 400 Invalid Model. Every single one. And because of the graceful degradation above, every upload still reported success.

Why nobody noticed

The visible symptom wasn't an error — it was a canonical-metrics dictionary slowly fragmenting into near-duplicates. Nothing about that looks like a bug from the outside. The metric everyone watches, "did uploads succeed," stayed at 100%.

Lesson: when a stage is designed to degrade instead of fail loudly, the success of the operation it's embedded in tells you nothing about whether that stage ran. You need a metric for the stage itself.

What actually caught it

Not an alert, not a test — there's no integration harness exercising the real pipeline. A routine cost audit noticed the LLM-matching cost line had gone quiet, which prompted someone to actually read the error logs. The diagnosis — 400 Invalid Model — had been sitting in the database the whole time, inside a raw error string, in a tooltip nobody had reason to open.

The fix wasn't more data, it was structuring what already existed: typed failure classification (error type, HTTP status, retryability) grouped by that classification instead of raw message text. 4× · 36% of matching calls · invalid_model is a bug report. Four chronological stack traces is a wall nobody reads.

The retry budget has to know your reverse proxy, personally

Extraction runs synchronously inside the upload request — no job queue yet. Nginx's proxy_read_timeout is 120s. If retry logic doesn't know that number: three 90-second retries run for 4.5 minutes against a socket Nginx already closed. Client gets a 504, server keeps working on nothing, report sits at "processing" forever.

Fix: a shared wall-clock budget (105s, deliberately under 120s) passed through both extraction and matching, so retries stop before the proxy would kill the connection anyway. Retries only happen for genuinely transient failures — a 401 isn't going to succeed on attempt two, and every retry is a real charge. A provider's Retry-After is honored as sent, not clamped — ignoring a rate limiter's instructions just earns another 429 faster.

Your retry budget and your proxy's timeout are the same constraint wearing two config files. Tune only one and you haven't fixed anything — you've just moved where the zombie request dies.

Takeaways

Give every "designed to degrade" stage its own visible failure-rate metric.
Structure error data at write time, not read time — you won't go back and re-parse a month of raw strings later.
Budget synchronous retries against your actual proxy timeout, explicitly, in the same unit.
Log the alias and the resolved concrete model, separately — "it worked yesterday" isn't debuggable if you can't tell whether the model changed underneath you.

👉 Try MyVitals now — the pipeline now tells on itself when something's wrong.

Building "Login As Mom" Without Building a Permissions System

Suyash Vashishtha — Sun, 06 Sep 2026 07:50:00 +0000

Every app with shared access eventually gets asked for "can my daughter manage my account for me." My instinct was full RBAC. What MyVitals actually needed — one person managing a household's lab reports — was closer to "let me act as this person entirely," not granular per-resource permissions. Building it safely was the interesting part.

The model: an invite is a membership, not a separate thing

FamilyMember is one row per (familyId, invitedEmail), representing a pending invite and an accepted membership as the same document transitioning state. userId stays null until the invited email matches an account.

One detail worth stealing: the invite token is cleared on acceptance via undefined, not null. There's a sparse unique index on it, and sparse indexes only exclude absent fields — null still counts as a value and collides the moment a second person accepts. One character between "works" and "second invite ever throws a duplicate key error."

The permission check is one function, and it is never cached

async function canActAs(trueUserId, targetUserId) {
  if (trueUserId === targetUserId) return true;
  return sharesAcceptedFamilyWith(trueUserId, targetUserId); // live DB read
}

Called on every request, not cached, not memoized. This is the decision I'd defend hardest: cache it and "removing someone revokes access immediately" becomes "...within roughly five minutes." One extra DB read per request buys a security property that's actually true instead of one that's true most of the time.

Query param, not header

?asUserId= — because some frontend call sites are plain <a href>/<img src> tags with no way to attach a custom header. A query param works everywhere a URL works.

Two identities, one footgun

req.effectiveUserId — whose data to read/write. Query by this.
req.actingUserId — who's really making the request, for audit fields.

Using req.userId directly in a new controller doesn't error — it silently breaks acting-as. A family member switches to their mother's profile, uploads a report, and it lands under the acting user's own account instead. No warning, just a report filed under the wrong person's medical history. There's no type system catching this (plain ESM JS) — it survives on convention and code review alone.

What this deliberately doesn't do

No granular permissions, no "view but not edit." Symmetric, all-or-nothing, targeting one person managing a household — not a care team with clearance levels. If that ever changes, this model gets replaced, not extended.

👉 Try MyVitals now — invite a family member and switch profiles in ten seconds.

Two Caches, One WebView, and a Deep Distrust of navigator.onLine

Suyash Vashishtha — Sat, 05 Sep 2026 07:48:00 +0000

MyVitals' mobile presence is a native WebView pointed at a remote URL — not bundled locally. If the phone loses signal in an elevator, a naive setup just shows nothing, forever, until signal returns. For an app about checking your health data anywhere, that's a bad joke.

Layer one: a service worker

Workbox precaches the app shell and runtime-caches API responses — standard stuff, if the service worker reliably registers and persists inside a native WebView, which varies by platform version and isn't something you fully control. So it's layer one, not the whole plan.

Layer two: the redundant one that actually saves you

A hand-rolled IndexedDB write-through cache at the axios level. Every successful GET gets written to IndexedDB; a shared useCachedQuery hook serves from it the instant a request fails instead of showing a spinner into the void:

try {
  const { data } = await apiClient.get(url);
  await idbCache.set(cacheKey(url), data);
  return data;
} catch (err) {
  if (!err.response) return idbCache.get(cacheKey(url));
  throw err;
}

Same data, two storage layers, on purpose. The service worker exists so the app shell loads at all in a WebView that's never had a chance to hit the network first; IndexedDB exists because the service worker might just not be there. A proactive prefetch sweep runs on login/reconnect so the cache is warm before the user goes offline — the goal is "you can't tell you're offline," not "gracefully handle it."

`navigator.onLine` will lie to your face

It reports whether the network interface is up, not whether it can reach anything — worse inside a WebView. Connectivity is a real network probe (GET /ping.txt, uncached), not a property read.

Writes are where I drew a hard line

Reads work offline. Writes don't — no offline write queue anywhere. Offline uploads/edits fail loudly with an inline message instead of queuing silently. This was deliberate: an offline write queue for a health app means conflict resolution, partial-sync failures, stale-queue edge cases — weeks of work for a single developer. Silent data loss is worse than an honest error, especially with someone's cholesterol on the line.

The bug waiting to happen: profile scoping

Both cache layers key on (endpoint, activeProfileId), not just the endpoint. MyVitals has family sharing — one login can "act as" a family member. Cache purely by URL and switching profiles means briefly showing your mother's cached dashboard under your session, or leaking yours into hers. If you're building offline support for anything multi-tenant, this is the bug that doesn't show up in your demo.

👉 Try MyVitals now — load your dashboard, then flip on airplane mode.

Teaching a Dictionary to Learn Instead of Hand-Curating It Forever

Suyash Vashishtha — Thu, 03 Sep 2026 19:46:45 +0000

"Fasting Blood Sugar (FBS)" in mg/dL from Lab A and "Glucose, Fasting" in mmol/L from Lab B, a year apart, are the same measurement. If your app can't figure that out, it can't draw a trend line — which is the entire point of MyVitals.

Four tiers, cheapest first, first match wins

Exact alias match — normalize the raw name, compare against known aliases. Instant.
Exact match on the extraction model's own guess (canonicalNameGuess) — added after a real bug, below.
Fuzzy similarity (Dice coefficient + token-set comparison) with a hard guard against matching "HDL" to "non-HDL Cholesterol" just because they're close.
LLM fallback — batched, retried, timeboxed.
Auto-create — mint a new entry. Report still saves. Dictionary just grew instead of getting smarter.

Whatever tier wins, the raw name gets appended as a new alias. The dictionary self-improves across every user — the fifth report where a lab prints "PCV" for hematocrit, tier 1 catches it instantly. That's the real moat: not "we can read a PDF," but "we get cheaper and more accurate with every report anyone uploads."

The bug that made two Hematocrits

The model's canonicalNameGuess used to be used only to name a new entry, never to find an existing one. Lab A prints "HCT," Lab B prints "PCV / Haematocrit" — neither raw name matches, fuzzy misses, both fall through to auto-create, and auto-create names both of them "Hematocrit" using the guess. Now you have hematocrit and hematocrit_1, splitting one measurement into two trend lines depending on which lab drew your blood — while the model had correctly identified both as Hematocrit the whole time. The pipeline just never asked.

Tier 2 (checking the guess against the dictionary before auto-create) fixed it — deliberately exact-only, never fuzzy, because a wrong merge puts two different analytes on one chart with zero indication it happened. That's worse than an extra row. Cleanup merged 14 duplicate groups, 126 → 112 metrics, full backup first, refused to run if any reading would come out worse.

Units lie in more creative ways than names do

µg/dL (micro sign) and μg/dL (Greek mu) and ug/dL (gave up on Unicode) are one unit in three costumes. The name-matching normalizer strips non-alphanumeric characters, collapsing all three into different strings that then compare as different units — 15 of 27 "unconvertible" readings turned out to be exactly this: correctly matched data, silently excluded from its own chart over a font rendering difference.

Fix: a second normalizer, used only for unit comparison, that knows µ/μ/u are the same prefix — and nothing else. It does not get to decide mg/dL ≈ mmol/L, or that μU/mL ≈ μIU/mL (one character apart, not the same unit). Any real equivalence claim needs a human to assert it explicitly. Correctness beats completeness when there's a chart on the other end.

👉 Try MyVitals now — upload an old report and watch it reconcile into a trend line.

I Wired 4 LLM Providers Into One Interface So I'd Never Have to Beg a Single Vendor for Mercy

Suyash Vashishtha — Thu, 03 Sep 2026 19:45:03 +0000

MyVitals reads your lab reports with AI. "AI" here is actually two different jobs wearing a trenchcoat:

Extraction — read a PDF, pull structured data out, needs strong vision + reliable structured output.
Chat — answer "is my TSH bad" fast and cheap, at conversational volume.

Bolting both onto one model is how you either overpay for reasoning nobody needed on a "thanks!" message, or starve extraction of the quality it actually needs. So they run on independently swappable providers:

LLM_PROVIDER=mistral        # extraction + metric matching
CHAT_LLM_PROVIDER=openai    # chat

Swapping either is a .env edit and a restart. Not a deploy. Not a refactor.

One interface, four adapters

Every provider — Gemini, OpenAI, Anthropic, Mistral — implements the same three methods: extractReport, matchUnmatchedMetrics, chat. No controller anywhere talks to a provider SDK directly. Four vendors also means four dialects of "give me JSON back" (responseSchema, json_schema strict mode, output_config.format, OCR annotation format) — normalized once behind a shared schema instead of four copies of prompt text slowly drifting apart.

Two billing models, one surprising economics fact

Mistral's OCR extraction is billed per page. Everything else is billed per token. Which means: a report upload costs roughly the same no matter how chatty your history is, but a chat message gets more expensive the longer you've used the product — because grounded chat means stuffing your entire metric history into the prompt every turn (no vector DB, deliberately — per-user data is small enough that RAG would solve a problem that doesn't exist yet). Your most retained users are mechanically your most expensive ones. Nobody puts that in the pitch deck.

The bug: `400 Invalid Model`, for a month, silently

MISTRAL_MODEL (goes to Chat Completions, used for metric matching) got set to an OCR-only model name. Every matching call failed with 400 Invalid Model for roughly a month — and nobody noticed, because the pipeline is designed to degrade: a failed matching call just falls through to auto-creating a new dictionary entry instead of finding the existing one. Every upload still reported success. The only symptom was a canonical-metrics dictionary quietly fragmenting in the background.

Lesson: if a stage is designed to degrade instead of fail, its failure rate needs its own visible metric — "the operation succeeded" tells you nothing about whether the expensive, accurate path ran at all.

Aliases in, concrete models logged

Env vars hold aliases (mistral-small-latest) so vendor upgrades land free. But logging the alias into a cost table is useless six months later. So the call goes out with the alias, and a resolver (cached 6h, never throws) logs what it actually resolved to — mistral-small-2603 — alongside the alias. Upgrade for free, keep history that still means something.

👉 Try MyVitals now — upload a PDF and watch it get read, matched, and charted.

How I boosted my App Performance up to 80%

Suyash Vashishtha — Mon, 07 Oct 2024 06:35:00 +0000

⌛ Recap Time

In my last blog I talked about how I Reduced my app size from 75MB to 34MB in just 2 weeks ( View ! ). But that's not all , I also improved overall performance of our app upto 80% 🚀.

Let's discover HOW !!

🕜 The Lore

After a simple round of walk through I discovered few of the top tier issues in our app leading to bad user experience and performance single headedly. What a day !

Main Villain - Whole App UI Frozen while generating Realtime response
Side Villain - Slow response time and No frame rates
Villain's lover - Too many Api calls
The Undead Army - Poor Error handling and crashes
Sufferings - More CPU usages and Server Costs
The Tarnished - ME !

Hence a lifeless battle of recreation of universe with a better world hope begins.

The Tahiti Plan ( But this time it works )

So I started with tackling the easier problems first as it is easy to ignore the great depression than fighting it on the moment.

1. ⚛️ Curse of React

The Wisdom and Curse of ReactJs is states. As we grow older in React we realize that lesser the states more better the application. Hence this particular piece of art was using 22 ( Yes goddamn 22 useStates) in a single chat screen where all you can do is send message and receive message.

Cherry on the top !
We were using Server Side event implementation for getting chunk-by-chunk data from server , which in case was word-by-word. So if you had a query which has a response of 100 words ( THIS IS LEAST OF RESPONSE ). It will actually receive 100 events.

So if you know the maths, 100*22 = 2200 re-renders each time we get a response.

Do I have to explain any further ? ( NO )

So I begin recreating the whole screen and took down the number to 6 states now. With better and smooth functionality as before.

That is 72% more performant that previous !!

2. ❄️ The Frozen Desert

Now after witnessing the Radahn of React, we can easily conclude that app is going to be freezing quite a lot right ?

Now even with 6 states, the main issue remains same it is 100*6. We are still hanging but with less states.

The main cause was, react dom getting updated on each chunk. So to tackle this we used "Batch Processing & Frame Rates Generation.

Hell Yeahh !

So basically instead updating the DOM each time we get a chunk, we were making batches of chunk and updating it in a fixed dynamic frame rate. These frame rates were called from OS so every device will have a different FPS as per system capacity giving the app more robust and compatible performance.

We captured a limited set of chunks in a batch and hold the response till the frame is released and repeated the same till all chunks are processed.

Hence instead of updating DOM 100 times we only updated DOM 3-4 times.

Now do the maths and calculate the performance enhancement for Homework !

3. 😊 Be a good listener !

It didn't work for me to get a girlfriend, but certainly worked to make the app much better.

Apis are cool and nice way to get data but using them wisely is a skill of your own ! Now this app was using this api to get the user status from backend. But the best part is it was using it every 3 seconds !!

I get it, developer had insecurities but this is not what they meant by bringing Work-life balance.

a) Fetching

In order to get the user data every time user uses the app, is to make the call at app start or every time app gets called from recent ( App state listener ). Calling it every 3 seconds not only uses Mobile resources into a infinite stream but also cause Server overhead .

Instead of getting 100 requests from 100 users, serve will get 100 request from 1 user. Doesn't sound very scalable and reliable to me.

As well as it creates untraceable memory leaks and usages which creates problem in longer usages.

b) Data Flow

Now after resolving that inhouse DDOS attack, I discovered that this app was using many apis whose data was getting ghosted in thin air ( Poor data handling ). Instead of caching data and using it again in same flow, the app was calling apis again.

I made sure data gets cached and flowed linearly to the flow and api is called only when needed for fresh instance.

Point to remember !

This resulted in better server health and less downtime for our backend due to too much api requests. As it costs company to run backend it is crucial to use apis effectively and only when needed

Not only for backend but for frontend as well, making extra api calls make it more system consuming as it has to do more HTTP handshakes and protocols every time you make a call.

3. 😎 Its not a Error if we don't acknowledge it !

One of the crucial thing for handling apis is, ERRORS. Consoling them to the logs isnt enough as it makes user's exp far worse than their good usages.

It is important to handle errors from any action using some kind of feedback system . It can be an Alert or Popup or Toast or anything. But user should know why and how it happened so that they can report it back or atleast get to know what they did wrong !

4. 💔 Her Memories

Gottacha homie ! She aint coming back but the memory leaks will. One of the main thing we forget while attaching any listener or Api call is to remove its instance after we close that activity.

This app had tone of it, api calls were getting called even after activity is closed or in background. Causing unnecessary CPU usage and resource hogging making app more laggy and hard to use.

Proper cleaning of these makes app more faster and less over heading.

5. Declaration of Performance

Now a basic way to use any asset is to import it and use it right ?

But do you know how it works ? Every time you default import an item it gets allocated into memory with an initialization. So if you import and declare a Image or component in 5 files like this

import Profile from '../../profile'

It will create 5 instances of it for the same thing !

Instead you should call all assets in one index file and import the object from it, that way it will only be declared once and will be used by Reference everywhere.

Hence reducing the memory usage to 4/5.

✅ Conclusion -

Your a good man Arthor ! ( Sorry I just completed RDR2 and it was a great great game ) .

With these changes the app performance boosted like hell with not just better mobile side health but as well as better Server side optimization.

The Store Rating went from 3.5 to 4.1 in just 1 week of using !!!

Remember it is not just a code but a story on how users interacts with it.

As a Frontend developer, the whole product depends upon us. No matter how scalable the backend is, the end product which user is going to use is out creation and it is the only thing they make decision on. So it is most important for us to give them a smooth interaction which leads to better business for the entire company.

🚀 Drop comments if you like the blog, or share it with your homies to let them enjoy it as well !

How I reduced my app size from 75MB to 34MB !!

Suyash Vashishtha — Fri, 27 Sep 2024 07:55:59 +0000

🕜 The Lore

So recently I was hired by Neurobridge Tech. as a Senior Mobile app developer to develop and lead end-to-end product development of their Flagship app Chanakya AI !

Wanna checkout the app?
Download Android
Download iOS

Now they already had the app released and users were using it quite a much. But the app size was around 75mb at that time. So naturally we had some issues with performance, scale, etc but we will discuss that in the next post.

Back to the lore, now as industry-standard a Simple app without any complex processing at the client side or 30-40 heavy animation screens, the app size should not be more than 25 MB; but as we are using Server side event handling and some advanced features, 35Mb is fine.

But here we are with a Big Chungas 75MB Asteroid Destroyer !!

The Realization....

I started by identifying where we were using spaces. After a good look ( I was traumatized by the code base ) I discovered that the whole app needs to be refactored with better code practices and more optimized manner
(Some things are beyond salvation )

The Recreation (But Better)

Hence after getting OCD from the old code base, I started making new architecture while referring to old ones.

Now here comes the main part -

1. 🛞 Reinventing Wheel

I noticed that previously we made different screens and components for the functionalities which were 80% the same ( Logged-in user and Guest user ) So I started by combining both flows to reduce the code base.

I deleted over 300 files of code and brought the whole code base to 75% less code ( 1500 lines of code to approx 350 lines ).

One of the things to always remember is that, if 2 or more modules have the same base functionality of over 70%, it is always better to keep them in a single source while maintaining a conditional execution.

2. 🖼️ The Collector

As development is a rapid thing in startups, we often forget to delete any unnecessary files or assets that might make our app heavy from shadows.

I analyzed and modularised whole images and assets and deleted the unused media leading to size reduction while bundling assets.

3. ♾️ Domain expansion - NPM Install

As more experienced you get, the more you realize that if it can be done manually then just do it.

Don't be that guy "Just one more module bro, I can remove it anytime I want"

Using Node modules for every little thing even when you can do it yourself isn't cool ! This Bad boi had 3.5GB of Node modules in it ( YESS the freaking GigaByte ) !

I don't know how it happened, and really not interested to know as well!

All I cared about was reducing it to minimal while recreating most of the functionalities and removing unused linked modules as native linked modules get bundled even if they are not used in JS code.

4. 🦚 Geeta Method - The Single Source of Truth

Often while developing a complex and interlinked application, we forget to make it modular and more globalized.

Previously we were using all values, methods, functions, etc by hardcoding them directly in place, which led to extra compilation and memory usage. Leading to a bad product.

I Modularized every reusable item ( variables, strings, functions, data handlers, etc ) to make sure everything gets initialized only once and then can be used by reference.

✅ Conclusion

With all this refactoring and carefully crafted code in 2 weeks, we were finally able to reduce the app size from 75MB to 34MB in stores.

A Smaller app not only runs faster but plays a crucial role in user traffic. Nobody wants a Big Chungus app with a slow process, everyone likes to keep it small, fast, and quick.

🎁 Bonus Content ( Cause why not )

While keeping the app size at best, I also made the whole app 🚀 80% faster in performance and reduced the Network request down to 50% ultimately leading to

Better server health
Less Loadings
Less Overheads
Less downtime
Less running cost
Scalability stonks
Low Latency
Fast UI/UX Flow

Sounds Cool right !?
Check out my next post to see how what I exactly used to make the system 80% efficient while keeping size and deps minimal!

Click here

Thanks for Reading my Homies!

Show some love in a comment or ask anything you like :)

👋 Until Next time!

How to Send Data while Navigating Back in React Native

Suyash Vashishtha — Mon, 30 Jan 2023 18:20:20 +0000

It is one of the most common issues in Mobile apps in React Native. We can send data from ScreenA to ScreenB in params but can't send data from ScreenB to ScreenA while navigating back!

But I have got a Hack!

In this blog, I am gonna tell you how to send data from ScreenB to ScreenA while navigating back.

Let's start by making Screen A

In ScreeA, I created a button to navigate to ScreenB with no data.

Setting up Screen B

Now in ScreenB let's make a similar button for going back, but instead of using navigation.goBack() we will use navigation.navigate() here.

Reason - In navigation.navigate() function, If the given path is present in the navigation tree, it will navigate to that path instead of creating a new one, else It will create a new path.

And as we know, ScreenA was already there in our navigation tree so navigation.navigate() will move to ScreenA which is technically our previous screen.

Now you might notice here, that the arguments are different from regular ones. Let me explain-

name - Screen/Route Name
data - data to be passed in routes
merge - true if you want to merge the data with the given screen.

With this, we can send data to ScreenA.

How to handle the new data in Screen A?

When we initialised the screen we didn’t mention any routes params data because there weren't any!
So how are we going to handle this new data in Screen A?

In ScreenA we will place a useEffect for new route data with a " ? " to check if the data key exists. Initially, the data key wouldn’t exist hence it will do nothing, but after navigating back from ScreenB it will get engaged and log the new data.

Basically we are forcing new route data into our ScreenA.

And POOF, we have our data from ScreenB!

Thanks for Reading !

React States works by Reference

Suyash Vashishtha — Mon, 30 Jan 2023 09:12:59 +0000

Today I learned something cool in React. I was trying to update a post in the list of Posts ( State ) but even after changing the element's key value, it wasn't reflecting in UI ( but showing updated data in the console log. I spent hours trying to figure out why it is happening and according to JS, I was doing the right array manipulation.

So I did some research and a GitHub thread finally guided me to the right track, comes out that the React States are used by references not by value.

"React compares by reference, in the setState(newState) call, you are just setting the state to the same list. Changing the contents of the list doesn't change the reference to the list. When the next state is the same as the old state, React bails out on doing any work.
One quick thing you can do is slice the array like this:

const newData = oldData.slice(0);
newData[0] = 'something'
setState(newData);
"

GitHub Thread

Here slice() returns a new array based on the given condition, so it breaks the state reference and creates a new array reference. Now React will take the new array as a different entity and will update the state.

React is a beautiful thing ❤️

How to show Loading wrapper in ReactJS / React Native while api call !

Suyash Vashishtha — Thu, 27 Oct 2022 21:17:50 +0000

No Introduction, Let's cut to the chase

You have an API and a component to show with data provided by API. Now the problem is, that component gets called before the API call is completed resulting in throwing an undefined or null error while calling children keys in a component.

To Resolve this we use something called a Loading Wrapper. Now, this method works on both React and React Native as it uses common useState and Reacts LifeCycles to work.

Step 1 - Maintaining a Loading State

Let's start by making a loading state to check and update our application whenever the loading starts and ends.


const [isLoading, setIsLoading] = useState(false)

Now we will update it to true when the call starts and false when the call ends.

Step 2 - Calling APi with Loading State

In this step, we will simply update the isLoading state to true and false to tell our application the current loading condition.


useEffect(()=>{
     getData()
},[])

const [isLoading, setIsLoading] = useState(false)
const [data, setData] = useState(null)

const getData = async()=>{
   setIsLoading(true)

   await axios.get(url).then((res)=>{
           setIsLoading(false)
           setData(res.data)
  })
  .catch(err=>{
           setIsLoading(false)
  })
}

What the hell did you do here ????????

Well I started by setting isLoading to true when our API call started ( just before Axios) and then to false when our promise finally ended ( either with success or failure )

Step 3 - Showing Loading wrapper based on this api call

Now our application knows if the API is loading or not, let's move to the rendering part.

We will use conditional rendering to render the diff UI based on diff cases.


return(
   !isLoading ?
      data!==null?
        <YourComponent data={data} />
      :
       <h1> Can't connect to server ! </h1>
   :
   <span> Loading... </span>
)

Here, we are first checking is isLoading is false, which means the API call has ended. So we will move to render our component. If isLoading is true it will show a span tag with text as Loading...

Then, we are checking if data!==null which means the API call has been success full and populated with backend data. If it is null that means the API call is failed and there is some error in the API call.

It is not really a part of Loading Wrapper but it is most commonly used with loading states to avoid crashes and undefined errors.

So Now our loading wrapper is ready, and each time the getData() function gets called it will again trigger the loading and our render function will act accordingly.

❤️🧑🏻‍💻Thanks for reading , If you liked this blog please drop a like and comment !

Looking for open source contributors in React Native !

Suyash Vashishtha — Mon, 17 Oct 2022 10:47:34 +0000

I am looking for open-source contributors to work with me on my cute little UI Kit for react-native.

Introduction

🙋🏻‍♂️ Hi, I am Suyash. I am React Native Developer from India and working on a small-scale UI Kit for react native.

I aim to provide some miscellaneous Ui elements that are either ugly or not available in react native default element collection. A common example is Alert [ Ugly AF in the android system ].

So why would you use my UI KIT when others are available huh?

Well, the answer is, I am trying to make all these elements without using any third library or dev dependencies so the support line would be maximum and you don't have to install some other stuff that u will never see in the whole dev.

Steps to participate

Note - Use the given theme or add the colors if u think that would look cool, but don't change the previous colors.

Fork The Repo from here
Start developing something
Submit a PR with a proper description of what your magical ✨ div ✨ does and also include the screenshots ( Gotta check the aesthetic ).
If everything goes right, I will merge them asap.

Don't have an Ideas right now ?

I gotta you, try to make these -
1. Alert Pop up ( Done )
2. Vertically scrollable tabs with onScroll tab Changing
3. TextInputs
4. Dropdown

DEV Community: Suyash Vashishtha

I Shipped an Play Store App That Updates Itself, Because There's Nothing in It to Update

The trade

"Finished loading" ≠ "actually works"

Bridging the back button

Making a website stop feeling clickable

Camera permission for a plain HTML input

The one screen the theming audit never reached

The Month My AI Pipeline Failed 100% of the Time and Every Log Said "Success"

Why nobody noticed

What actually caught it

The retry budget has to know your reverse proxy, personally

Takeaways

Building "Login As Mom" Without Building a Permissions System

The model: an invite is a membership, not a separate thing

The permission check is one function, and it is never cached

Query param, not header

Two identities, one footgun

What this deliberately doesn't do

Two Caches, One WebView, and a Deep Distrust of navigator.onLine

Layer one: a service worker

Layer two: the redundant one that actually saves you

navigator.onLine will lie to your face

Writes are where I drew a hard line

The bug waiting to happen: profile scoping

Teaching a Dictionary to Learn Instead of Hand-Curating It Forever

Four tiers, cheapest first, first match wins

The bug that made two Hematocrits

Units lie in more creative ways than names do

I Wired 4 LLM Providers Into One Interface So I'd Never Have to Beg a Single Vendor for Mercy

One interface, four adapters

Two billing models, one surprising economics fact

The bug: 400 Invalid Model, for a month, silently

Aliases in, concrete models logged

How I boosted my App Performance up to 80%

⌛ Recap Time

🕜 The Lore

The Tahiti Plan ( But this time it works )

1. ⚛️ Curse of React

2. ❄️ The Frozen Desert

3. 😊 Be a good listener !

a) Fetching

b) Data Flow

3. 😎 Its not a Error if we don't acknowledge it !

4. 💔 Her Memories

5. Declaration of Performance

✅ Conclusion -

How I reduced my app size from 75MB to 34MB !!

🕜 The Lore

The Realization....

The Recreation (But Better)

1. 🛞 Reinventing Wheel

2. 🖼️ The Collector

3. ♾️ Domain expansion - NPM Install

4. 🦚 Geeta Method - The Single Source of Truth

✅ Conclusion

🎁 Bonus Content ( Cause why not )

Thanks for Reading my Homies!

How to Send Data while Navigating Back in React Native

But I have got a Hack!

Let's start by making Screen A

Setting up Screen B

How to handle the new data in Screen A?

React States works by Reference

How to show Loading wrapper in ReactJS / React Native while api call !

Step 1 - Maintaining a Loading State

Step 2 - Calling APi with Loading State

Step 3 - Showing Loading wrapper based on this api call

❤️🧑🏻‍💻Thanks for reading , If you liked this blog please drop a like and comment !

Looking for open source contributors in React Native !

Introduction

So why would you use my UI KIT when others are available huh?

Steps to participate

Don't have an Ideas right now ?

Either way, you are always welcome to use the KIT, provide review or have a nice talk about it ☕️

`navigator.onLine` will lie to your face

The bug: `400 Invalid Model`, for a month, silently