DEV Community: Vikrant Negi

6 Mistakes I Made Running My First Controlled Experiment as a Developer

Vikrant Negi — Mon, 26 Oct 2026 14:00:00 +0000

I've been a developer for about ten years. I know how to find out whether code works: write a test, run it, read the output.

Finding out whether code helps people is a different job. I learned that by getting it wrong, repeatedly, over five weeks.

The project was an AI tutor for SQL with two versions, called arms. Arm A makes you try before it helps. Arm B gives the answer whenever you ask. Six people practised with one version or the other, then took a test a week later with no tutor. (Part 1 of this series has the full story and result.)

I kept a log of every assumption that broke. It ended up with 24 entries. Most of them are the same few mistakes in different clothes. Here are the six worth knowing about before you run an experiment of your own, whether it's a learning study or an A/B test on a feature.

1. The test measured a different skill than I thought

Before the study, I screened seven people with a written SQL test. No database, no Run button. Just write the query.

They solved 4 of 35 questions they attempted.

One colleague scored 0 out of 10. All four of his answers were conceptually right. He lost every mark to one habit: putting the sort direction in quotes. One run against a real database would have shown him the error.

Five days later, same people, I added a Run button. They solved 11 of 16.

Same people, one change. The first test wasn't measuring SQL skill. It was measuring "can you write perfect SQL in one shot with no feedback", which nobody does at work.

The rule: a test only predicts performance under the conditions it recreates. Before trusting a number, ask what conditions produced it. Then ask whether those are the conditions you care about.

2. I counted at the wrong grain

Four of my 24 logged mistakes were this one. I had real numbers, but counted at the wrong level.

The effect I cared about lives at one learner on one question. I called that a person-question. Three learners × 12 questions = 36 person-questions per arm.

But I kept slipping into "per person" or "per question" without noticing. Per person, I had 3 data points per arm, which tells you almost nothing. Per question, I mixed strong and weak learners together and hid who was struggling.

The worst version came early. I planned the study around "3 learners × 16 questions gives 48 moments where the tutor has to decide what help to give". But a question you solve on the first try needs no help. Neither does one you never open. So the real event isn't "a question asked". It's "a question where the first working attempt is wrong".

When I measured that rate, it was about 1 in 7 person-questions. The same 48 person-questions would give me about 7 help decisions, not 48. I had to cut the study from two topics down to one to have anything to measure.

The rule: for every number, say its unit out loud. "25 of 36" means nothing. "25 of 36 person-questions (3 learners × 12 questions)" can be checked.

3. "No help" is still a design

Arm B was my control: the version I compared the new idea against. It gave the answer on demand, and otherwise just showed the database's error message. I treated that as neutral. It wasn't.

One learner made 80 attempts in 47 minutes. None of them ran. His only real problem was writing keywords without a space: GROUPBY instead of GROUP BY.

SQLite's error message names the word after the broken one. So it pointed him at the wrong place. He rewrote his column names. He rewrote the HAVING line four different ways. In 63 tries on one question, he never touched GROUPBY.

Here's the trap. Suppose the bare error message is bad in a specific way, and the new version happens to fix that. Then part of the improvement you measure is just that fix, not the idea you were testing.

The rule: a control group is a design choice, not the absence of one. "No help" still has a user experience. Look at it as carefully as the new version.

This applies directly to A/B tests. If your control is the old checkout with a known confusing button, and your variant fixes the button, you might credit your new feature for the button fix.

4. Question order was a variable, and I didn't count it

The 12 test questions ran in skill order. Simple skills first, the hardest skill last.

Three of six learners stopped early, after question 8 or 9. Some ran out of time. Some gave up. On narrow screens, the question list cut off after question 9, so some may not have seen the rest.

Because of the order, every early stop landed on the hardest skill. So my biggest gap between the arms, 6 points on the hardest skill, was really just 6 blank answers.

That's the worst kind of hidden bias. It doesn't add random noise. It produces a clean-looking result in exactly the place you were going to read most carefully.

The rule: anything that changes along with the outcome is a variable, even page order. Randomise order per user, and log it.

5. Being in the group is not the same as using the feature

Arm A's whole difference is what happens when you press Help. If you never press it, both arms are the same page.

Three of my learners never pressed Help during practice. One of them was in Arm A. He never experienced the try-first tutor at all, and still scored 12 of 12 on the test.

My headline result counted everyone in the arm they were assigned to: 36 vs 25, an 11-question gap. Counting only the four people who used Help as designed, the gap was 24 vs 21. Three questions.

Both numbers are honest. They answer different questions. "What happens if you give people this tool?" versus "What happens when people actually use it?" You need both, and you need to say which is which.

The rule: log what each user actually received, not just which group they were in. Report both side by side.

In product terms: if half your variant group never saw the new feature because it's below the fold, your A/B test is mostly measuring the old page twice.

6. I didn't say the study was unsupervised

This is the one a judge caught at Demo Day.

He asked whether the practice and the exam were done live. They weren't. Learners got a link and did it in their own time. That wasn't on my slides, and he'd assumed it was live.

Unsupervised means you can't see what else people used. Google. ChatGPT. A friend.

And it's not equal across arms. Arm B learners never needed to leave the page; the answer was one click away. Arm A learners were held at a gate until they made an attempt. That's exactly when you'd open ChatGPT in another tab.

If they did, they skipped the struggle that Arm A exists to create. That weakens Arm A's tutor only, and pulls the result toward "no effect". The unsupervised exam does something similar: outside help lifts both arms and shrinks the gap.

So my setup most likely made the result look weaker, not stronger. That's a good thing to be able to say. I just didn't say it, so the audience filled the gap with their own default.

The rule: if a condition would change how someone reads your result, it goes on the slide. Live or remote. Supervised or not. Who dropped out. People assume the standard version of whatever you leave out.

The one habit that saved me

Before I saw a single answer from the test, I wrote down how I'd read the result. That included ten checks that could break it. Things like "neither arm above 80%", so there's room to see a difference, and "Arm B tries less than Arm A before asking for help", so the arms actually behave differently.

Two of those checks failed. Arm A hit 100%. Arm B tried before asking for help almost as often as Arm A.

Because I'd written the checks first, I couldn't explain them away. I had to change my claim. My hypothesis went from "trying first improves recall" to "trying first changes what you do after a wrong answer". That change is the most useful thing the project produced.

If you take one thing from this post: write down what would prove you wrong before you look at the data. It's the same discipline as writing a failing test before the fix. Ten years of TDD habits turned out to transfer after all.

Key takeaways

Check the conditions. A test measures the skill its conditions recreate, not the one you named it after.
Check the grain. Give every number its unit, and make sure it's the unit where the effect lives.
Design your control. "No change" has its own UX, and that UX can create your result.
Randomise anything ordered. Position is a variable.
Log who actually used the feature. Being in a group and using the feature are different numbers. Report both.
State your setup. Your audience will assume the default for anything you don't say.

All the logs, including the 24 broken assumptions, are in the repo:

vikrantnegi / withholding-pilot

Learning OS — 100x Cohort 7 final capstone

Vikrant Negi. Solo. Demo Day track. Submission 7 Oct 2026.

An SQL tutor that makes you try before it helps, and a 6-person pilot testing whether that changes what you can do a week later, with the tutor gone.

For where things stand today, read STATUS.md. That is the only file that claims to be current.

Try it

Live app: https://tranquil-starlight-f0129e.netlify.app/

Withholding tutor: https://tranquil-starlight-f0129e.netlify.app/index.html?arm=A
Answer-giving baseline: https://tranquil-starlight-f0129e.netlify.app/index.html?arm=B

What each one does:

?arm=A opens the withholding tutor. Press Help before trying, and it refuses. Try once, and Help gives a hint. Two more tries, and it gives the answer.
?arm=B opens the baseline. Help gives the full answer at once.

Same page, same 16 practice questions, same grader. One config flag is the only difference.

The result

Arm A scored 36 of 36 person-questions (3 learners x 12 held-out questions). Arm…

View on GitHub

Which of these have you hit in your own A/B tests? I'd bet #5 is the most common one in product teams. Please feel free to leave any feedback.

Don't Let the LLM Decide: How I Built a Predictable AI Tutor

Vikrant Negi — Mon, 19 Oct 2026 14:00:00 +0000

The easy way to build an AI tutor is to give the LLM everything. Pass it the question, the learner's attempts and the answer. Tell it: "Help the learner, but don't give the answer away too early."

That works in a demo. It fails in an experiment. And it fails quietly in production too.

In the first post of this series I explained the experiment. I built an SQL tutor in two versions, called arms. Arm A makes you try before it helps, then gives a hint before the answer. Arm B gives the answer whenever you ask, like most AI tools. Six people used one or the other, then took a test a week later with no tutor.

This post is about how I built it. The core rule fits on one line:

The LLM never decides whether to help, or how much. Plain code decides. The LLM only writes the hint's wording, after that decision is made.

Why the LLM can't be the one deciding

Picture the prompt version. "If the learner seems stuck, give a hint. If they've really tried, give the answer."

Now try to answer one question: what did Arm A receive?

You can't. "Seems stuck" is a judgment the model makes fresh every time. Two learners in the same situation can get different help. The same learner can get different help on a retry. The thing you're trying to test becomes a moving target.

There's a second problem. With six people, there were only about 23 moments in the whole study where the tutor had to decide what help to give. You can't judge a model's decision-making from 23 examples. But you can fully test a plain function, and I did, with 123 unit tests.

So I split the system into three kinds of parts, a framing from my 100x Engineers AI course:

part	does what	why it sits there
human	writes and runs SQL	the skill being measured is theirs
deterministic (plain code)	the try-first rule, the hint/answer rules, the answer checker, the leak guard	the one thing being tested must be fixed and checkable
probabilistic (the LLM)	writes the hint text, nothing else	prose about this specific mistake is the one thing code can't write

The model is one small component. It's not the product.

The policy: a pure function

Here's the heart of policy.js, trimmed. No DOM, no network, no LLM. It takes the log for one question and returns an action.

const ACTION = {
  NONE:         'none',          // already solved
  REFUSE_GATE:  'refuse_gate',   // Arm A, no real attempt yet
  REFUSE_RETRY: 'refuse_retry',  // Arm A, hint given, keep trying
  HINT:         'hint',          // the LLM writes the text
  REVEAL:       'reveal',        // the reference query
};

const DEFAULT_N = 2; // attempts with the hint before the answer

function decide(item) {
  const N = item.N ?? DEFAULT_N;
  const counted = countableAttempts(item.attempts);
  const helpServed = item.helpServed || [];

  if (item.attempts.some(a => a.outcome === 'correct')) return { action: ACTION.NONE };

  // Arm B: the entire difference between the two groups is this line.
  if (item.arm === 'B') return { action: ACTION.REVEAL };

  // Arm A: the gate. No help of any kind until one attempt counts.
  if (counted.length === 0) return { action: ACTION.REFUSE_GATE };

  if (helpServed.some(h => h.action === ACTION.REVEAL)) return { action: ACTION.REVEAL };

  const hint = helpServed.find(h => h.action === ACTION.HINT);
  if (!hint) return { action: ACTION.HINT };

  const sinceHint = counted.length - hint.afterCountedAttempts;
  return sinceHint >= N ? { action: ACTION.REVEAL } : { action: ACTION.REFUSE_RETRY };
}

The only thing of interest here is the Arm B line. That one if is the whole difference between the two versions. Anyone can read it and know exactly what each group got.

Every decision is logged with counted and sinceHint. So for any Help press, I can look at the log and prove why the tutor responded the way it did.

N is fixed at 2 for everyone. If it changed per person, I'd be testing two things at once, and three people per group can't separate them.

What counts as an attempt?

Arm A's rule is "try first". I call it the gate: no help until you've made an attempt. So the code needs to decide what a real attempt is. This turned out to be the hardest part of the policy.

My first version said: an attempt counts if its result set is different from the last one. Simple, and wrong.

The bug: a query that doesn't run has no result set. So for a learner who couldn't get anything to execute, no attempt ever counted. The gate never opened. In my earlier test rounds, 101 of 122 attempts had a syntax error and didn't run. This wasn't an edge case. It was the main case.

And a query that fails to parse can still carry a full, wrong mental model:

SELECT customer, COUNT(*) FROM orders WHERE COUNT(*) > 3

That doesn't run. It's also a perfect example of the exact mistake I was teaching about (filtering groups with WHERE instead of HAVING). It should count.

But asdf doesn't parse either. If junk counts, a learner can type three bits of junk and get a hint while thinking about nothing. Research on tutoring systems calls this "gaming the system", and learners find that shortcut fast.

So I added a substance bar. An attempt must contain one SQL keyword and one name from this question's schema:

function isSubstantive(sql, identifiers) {
  const low = String(sql ?? '').toLowerCase();
  if (!low.trim()) return false;
  if (!SQL_KEYWORDS.some(k => low.includes(k))) return false;
  if (!identifiers.length) return true; // fail open, see below
  return identifiers.some(id =>
    id.length >= 4
      ? low.includes(id)
      : new RegExp(`\\b${id}\\b`).test(low) // so "id" doesn't match "video"
  );
}

Matching is by substring on purpose. Real learners wrote GroupBy and havingcount>=3. That's mangled spelling, but a real mental model. A strict token match would throw those away.

I checked it against all 128 attempts from the screening round. 121 passed. The 7 rejected were 6 empty submissions and one bare SELECT. No real attempt was lost.

Notice the fail open line. If the schema list fails to load, the bar only checks for a keyword. A misconfigured page must not silently refuse every learner. That would turn Arm A into "no help at all" without anyone noticing.

The leak guard

Here's the uncomfortable part. To write a useful hint about a wrong query, the LLM has to see the correct one. I call that the reference query. So it's holding the answer while it writes. Sometimes it just prints it.

If that reaches the learner, Arm A quietly becomes Arm B on that question. The experiment stops testing anything, and nothing in the logs looks wrong.

So every hint passes through hint-guard.js before the learner sees it. It's deterministic. It makes no model calls. It looks at text and says yes or no.

function inspect(hint, { referenceQuery, learnerQuery }) {
  // 1. A runnable query: SELECT plus a real table after FROM/JOIN.
  // 2. A clause that distinguishes the reference query,
  //    unless the learner already wrote it themselves.
  // 3. Too much of the reference reproduced word for word.
  // 4. A walkthrough: four or more SQL keywords named.
}

If a hint is rejected, the system asks the model once more. If that fails too, it serves a hand-written fallback for that question. Every attempt and every rejection is logged.

Results: on 101 real hints, zero false alarms. Against 24 leaks I wrote specifically to beat it, it caught 22.

What can go wrong

Each rule in the guard exists because an earlier, simpler rule broke.

"SELECT and FROM means a leak." My first check rejected any hint containing both words. But they're normal English. "You started with SELECT, but where does the data come FROM?" is a great hint, and it got blocked. The fix: a runnable query must name a real table. The reference query tells you which tables exist, so look for those.

The semicolon rule. I also rejected "select ... ;" on the idea that a semicolon ends a statement. English uses semicolons too. "Nothing is processed; you need to say where the data comes from" got blocked. I deleted that rule instead of patching it, because the table rule already covered real queries.

Quoting the learner back to themselves. The prompt asks the model to quote what the learner wrote. So a hint would say "your MAX(price) is fine". MAX(price) is part of the answer, so the guard blocked it. 7 of 8 rejections in one test run were this. But the learner already wrote it. It's in their editor. Now a clause only counts as a leak if the learner doesn't already have it.

The leak with no SQL in it. "The FROM keyword picks the products table, then GROUP BY groups the rows by category..." No clause appears verbatim, but you could type the answer straight from it. The signal is shape, not content. A real hint talks about one or two things. A dictation names everything.

I didn't pick the threshold by feel. I measured it. Across the 101 real hints: 66 named no SQL keyword, 29 named one, 5 named two, 1 named three, and none named four. The two prose leaks named six and seven. A limit of four separates them with room on both sides.

The silent fallback. The LLM sits behind a Supabase edge function, so the API key never reaches the browser. Supabase pauses free projects after about a week without traffic. When paused, nothing errors. Arm A just serves the hand-written backup hints. The app looks fine, but it's quietly running a different tutor. I found this once, fixed it, and added a script to check it before every session.

What this means for your code

If you're putting an LLM into a product, ask one question about each decision: does this need judgment, or does it need to be the same every time?

If the behaviour has to be explainable, testable or consistent, it belongs in code.
If it needs language about this specific case, that's what the model is for.
Put a deterministic check between the model and the user for anything that would be expensive if the model got it wrong.

In my tutor, that split is why I could say exactly what each group got. It's also why the experiment could fail honestly. When two of my checks failed, I knew the failure was about learners, not about a model behaving differently on a Tuesday.

Next in the series: the mistakes I made running my first controlled experiment as a developer, including the one a Demo Day judge caught.

vikrantnegi / withholding-pilot

Learning OS — 100x Cohort 7 final capstone

Vikrant Negi. Solo. Demo Day track. Submission 7 Oct 2026.

An SQL tutor that makes you try before it helps, and a 6-person pilot testing whether that changes what you can do a week later, with the tutor gone.

For where things stand today, read STATUS.md. That is the only file that claims to be current.

Try it

Live app: https://tranquil-starlight-f0129e.netlify.app/

Withholding tutor: https://tranquil-starlight-f0129e.netlify.app/index.html?arm=A
Answer-giving baseline: https://tranquil-starlight-f0129e.netlify.app/index.html?arm=B

What each one does:

?arm=A opens the withholding tutor. Press Help before trying, and it refuses. Try once, and Help gives a hint. Two more tries, and it gives the answer.
?arm=B opens the baseline. Help gives the full answer at once.

Same page, same 16 practice questions, same grader. One config flag is the only difference.

The result

Arm A scored 36 of 36 person-questions (3 learners x 12 held-out questions). Arm…

View on GitHub

Try both arms live: Arm A · Arm B

Should an AI Tutor Just Give You the Answer? I Tested It

Vikrant Negi — Mon, 12 Oct 2026 14:00:00 +0000

I built an AI tutor for SQL that won't hand you the answer straight away. Then I tested it against a normal version that does.

Six people practised with one version or the other. A week later, they took a 12-question SQL test with no tutor at all.

The "try first" group got all of their answers right: 36 of 36 (3 people × 12 questions).
The "give me the answer" group got 25 of 36.

That looks like a clear win. But when I presented it at my course's Demo Day, I told the room I don't credit the win to my tutor.

This post explains why. It also covers the one question from a judge that I wish I had answered on my slides.

The question

This was my final project for the 100x Engineers AI course. I wanted to answer one design question every AI tutor faces:

When a learner is stuck and presses Help, what should the tutor give them?

Most tools give the answer. ChatGPT does. Copilot does. It feels helpful, and the learner moves on.

But a large study (Bastani and colleagues, PNAS 2025) should worry anyone building these tools. Students who practised maths with an AI that gave answers did worse on a later exam than students who had no AI at all. Once the AI was gone, they were worse off.

So I asked a narrower question:

If the tutor makes you try first, and gives a hint before the answer, can you do more a week later, once the tutor is gone?

What I built

An SQL tutor on one web page. You read a question in plain English, write a SQL query, and press Run. The page tells you if you're right. When you're stuck, you press Help.

What Help does is the whole experiment. I built two versions of the page. In experiment-speak, each version is called an arm, so you'll see "Arm A" and "Arm B" below.

when you press Help	Arm A: try first	Arm B: give the answer
before you've tried anything	refuses: "give it one run first"	shows the answer
after one attempt	a hint, written by an LLM	shows the answer
after two more attempts	shows the answer	shows the answer

Arm B is the baseline: it behaves like most AI tools do today, so it's what I compare Arm A against.

Everything else was identical: the same page, the same 16 practice questions, the same checking. One setting was the only difference.

A judge at Demo Day called the experiment "arm wrestling". The name stuck, so it's the name of this series.

How the test worked

Six people took part, mostly developer colleagues. Three used Arm A and three used Arm B. I split them so both groups had similar SQL skill, based on two earlier rounds of testing.

Practice. 16 SQL questions on GROUP BY and HAVING, with the tutor.
Wait 5 to 7 days.
Final test. 12 new questions on the same skills. No Help button for anyone.

Step 3 is the point. I didn't care how well people did with the tutor. I cared what they could still do once it was gone.

Before I saw any results, I wrote down how I would read them. That included ten checks that, if they failed, would mean the result couldn't be trusted. More on why that mattered below.

The result

Each group had 3 people answering 12 questions, so 36 answers per group.

out of 36 answers	Arm A: try first	Arm B: give the answer
correct, after any number of tries	36	25
correct on the first try	17	17
questions they at least opened	36	29
wrong first tries they went on to fix	19 of 19	8 of 12

Look at the second row. On the first try, the two groups were identical: 17 each.

So the tutor didn't make anyone better at writing a correct query from memory. The whole gap came from what people did after a wrong answer:

Arm A opened every question. Arm B left 7 blank.
Arm A fixed all 19 of its wrong first tries. Arm B fixed 8 of 12.

That's not what I predicted. I expected people to remember more. What I saw was people who kept going and fixed their mistakes.

Why I don't claim the win

This is the part I'm proudest of, even though it looks like a loss.

Two of my ten checks failed.

The groups didn't behave as differently as planned. Arm A's whole idea is "try before you get help". That only matters if Arm B people don't try first. But they did. On average, Arm B people made almost one attempt (0.83) before pressing Help anyway. So Arm A didn't create a habit that Arm B lacked.

The test was too easy for Arm A. Arm A scored 100%. When a group hits the top score, you can't tell how far ahead it really is. Maybe it was just ahead by a little.

Then two things skewed the result that I hadn't planned for.

Question order. The 12 questions ran from easiest skill to hardest. Three people stopped early, so they all missed the hardest questions. My biggest gap between the groups, 6 answers on the hardest skill, was really just 6 blank answers.

Not everyone used Help. One Arm A person never pressed Help during practice. So he never experienced the "try first" tutor at all, and he still scored 12 of 12. If I count only the four people who actually used Help, the gap shrinks from 11 answers to 3.

Put together: the result leans toward "try first". But I can't say "try first" caused it.

So the claim I can defend is narrower:

Making learners try first seems to change what they do after a wrong answer. It did not change what they could get right on the first try.

The judge's question

At Demo Day, a judge asked: "Were the practice and the test done live, with you watching?"

They weren't. I sent each person a link, and they did it in their own time.

He said that wasn't on the slides, and he had assumed it was live.

He was right to ask. It changes how you read the result.

When someone works unsupervised, you can't see what else they used. A ChatGPT tab is one Cmd+Tab away.

And it doesn't affect both groups equally. Think about who has a reason to leave the page:

Arm B people have no reason. The answer is one click away.
Arm A people are blocked until they make an attempt. That's exactly when you'd paste the question into ChatGPT.

If Arm A people did that, they skipped the struggle the tutor was built to create. That makes Arm A's tutor less effective than it should be, and shrinks the gap between the groups.

The final test was unsupervised too. If people looked things up there, both groups score higher, and the gap shrinks again.

So working unsupervised probably made my result look weaker than it really was, not stronger. That's a good story. I just didn't tell it, because it wasn't on the slide.

The lesson: if a detail about how you ran the test would change how someone reads the result, put it on the slide. If you leave it out, people assume the standard version, and that may not be what you did.

What I'd do differently

Shuffle the question order for each person. Then stopping early doesn't always hit the hardest questions.
Use harder test questions, so neither group can score 100%.
Make "correct on the first try" the main score. It's the number my new prediction says won't change. That makes it the number that could prove me wrong.
Track who actually used the feature. Someone who never presses Help never experienced the tutor.
Run the test live, or at least log when people switch tabs or paste.

Key takeaways

A big gap can come from somewhere you didn't look. 36 vs 25 looked like better memory. The first-try row showed it wasn't.
Write your checks before you see the results. That's the only reason I could say "two checks failed" instead of explaining them away afterwards.
Changing your prediction isn't failing. Mine moved from "people remember more" to "people recover better". That change is the most useful thing the project produced.
Say how you ran the test. Live or unsupervised, question order, who actually used the feature. Readers fill in any gap with their own assumption.

Next in this series: how I built the tutor so that the LLM never decides whether to help. Plain code makes that decision, and the LLM only writes the hint. That one rule is what made the experiment possible to check.

The app is live, and you can try both versions:

Arm A, try first: https://tranquil-starlight-f0129e.netlify.app/index.html?arm=A
Arm B, give the answer: https://tranquil-starlight-f0129e.netlify.app/index.html?arm=B

vikrantnegi / withholding-pilot

Learning OS — 100x Cohort 7 final capstone

Vikrant Negi. Solo. Demo Day track. Submission 7 Oct 2026.

An SQL tutor that makes you try before it helps, and a 6-person pilot testing whether that changes what you can do a week later, with the tutor gone.

For where things stand today, read STATUS.md. That is the only file that claims to be current.

Try it

Live app: https://tranquil-starlight-f0129e.netlify.app/

Withholding tutor: https://tranquil-starlight-f0129e.netlify.app/index.html?arm=A
Answer-giving baseline: https://tranquil-starlight-f0129e.netlify.app/index.html?arm=B

What each one does:

?arm=A opens the withholding tutor. Press Help before trying, and it refuses. Try once, and Help gives a hint. Two more tries, and it gives the answer.
?arm=B opens the baseline. Help gives the full answer at once.

Same page, same 16 practice questions, same grader. One config flag is the only difference.

The result

Arm A scored 36 of 36 person-questions (3 learners x 12 held-out questions). Arm…

View on GitHub

If you've built anything that decides how much an AI should help, I'd love to hear how you measured it. Please feel free to leave any feedback.

Why LLMs Can't Count Letters (And How They Fake It)

Vikrant Negi — Tue, 23 Jun 2026 17:13:16 +0000

You've probably noticed this:

Ask a language model to count the letters in "strawberry" and it'll confidently give you the wrong answer.
Ask it to rhyme "entrepreneur" and it fumbles.
Ask it to fix a typo in "teh quick brown fox" and it handles it without blinking.

Same model. Wildly different results. Why?

The answer isn't "the model is bad at spelling." It's in how these models actually read text, and it's not what most people assume. Once you see the mechanism, you can predict which of these tasks a model will nail and which it'll botch, before you even run it.

The model never sees your text

When you type a message into an LLM, the model doesn't receive a string. It receives a sequence of integers.

Before your input ever touches the neural network, it passes through a tokenizer: a separate component that converts raw text into token IDs. The string "strawberry" might become [496, 19772]. That's what the model works with.

The tokenizer is trained separately, before the LLM itself, and then frozen. The model never updates it. It just inherits whatever mapping the tokenizer learned. So the very first thing that happens to your prompt is a lossy translation the model has no say in.

How that mapping gets decided: BPE

The algorithm most modern LLMs use is called Byte Pair Encoding (BPE).

Here's the mechanism in one sentence: BPE starts with individual characters as the vocabulary, then repeatedly merges the most frequently co-occurring pair of tokens in the training corpus, until it hits a target vocabulary size.

So it starts with the characters: s, t, r, a, w, b, e, r, r, y

Then it notices which pairs show up together constantly and merges them: s·t·r·a·w collapses into straw, b·e·r·r·y collapses into berry. And so on, until the vocabulary stabilizes at a target size (GPT-4 uses ~100,000 tokens).

The result: "strawberry" might tokenize as ["straw", "berry"], not because those are linguistically meaningful units, but because those byte sequences were frequent enough in training data to survive the merges.

This is the key intuition: the splits track frequency, not grammar. Common words like "the" become a single token. Rare or technical words get shredded into pieces. A word like "thransformer" (a typo) might become 4 or 5 tokens the model has never seen grouped that way.

The information that gets thrown away

Here's the thing that matters: once a sequence of characters becomes a token ID, the characters are gone.

The model sees 19772 (or whatever integer maps to "berry"). It does not see b, e, r, r, y. There's no "look inside the token" operation. No character-level access. The sub-token structure is destroyed at tokenization and never passed forward.

This is why counting letters is hard. When you ask "how many R's in 'strawberry'?", the model has to reconstruct character-level information from statistical patterns in training data, even though strawberry is just two opaque integers to it. It might have seen this exact question answered correctly often enough to get it right. It might not. There's no reliable mechanism, just pattern matching over a destroyed signal.

Same reason rhyming is unreliable. Rhymes are about sound patterns at the character level. The model has no direct access to those. It's working from memory of what it's seen rhymed before, not from actual phoneme analysis.

Quick gut-check: before reading on, predict it yourself. Spelling a word backwards, easy or hard for an LLM? (Hard. Same reason as counting letters: it requires character-level access the token ID doesn't carry.)

So how does it handle typos?

This is the interesting part, and the apparent contradiction.

If the model has no character-level access, how does "teh quick brown fox" get correctly interpreted as "the quick brown fox"?

The answer is attention.

The model attends to every token in relation to every other token in the sequence. "teh", even though it has a different integer ID than "the", appears surrounded by the same context tokens: "quick", "brown", "fox". The model has seen "the" in exactly that context billions of times during training. The attention mechanism builds a contextual representation of "teh" that ends up in the same neighborhood as "the" in the model's internal space.

It's not correcting the typo. It's representing the token based on what surrounds it, and that representation ends up semantically equivalent.

This works because "teh" is a common typo. It appears frequently enough in training data, in the same contexts as "the", that the model has learned to bridge them.

Where this breaks down

Apply the same logic and you can predict where it'll fail. Three places it gets shaky:

A misspelled rare technical word, like "thransformer" instead of "transformer", is much harder to recover. The correct word appears less frequently in training data to begin with, and the broken form has even less signal. Attention can try, but the weights aren't there to make a confident bridge.
A misspelling in an ambiguous context, where multiple words could fit, is also risky. The context constraint that makes "teh" obvious doesn't apply when the surrounding tokens don't narrow things down.
Anything that needs precise character-level reasoning, like counting letters, detecting palindromes, generating anagram lists, or strict rhyming, is fundamentally unreliable. Not because the model is dumb, but because the information was structurally discarded before the model ever ran.

The mental model worth keeping

BPE and attention are complementary by design:

BPE trades character structure for compression efficiency. Fewer tokens means shorter sequences, which means cheaper and faster inference.
Attention partially compensates by using context to recover meaning that the token IDs alone don't carry.

The system works well for what language is mostly made of: common words, common patterns, common errors. It degrades gracefully, not catastrophically, on the edges.

But it's worth knowing where those edges are. Next time a model struggles with something that seems trivially easy (count the letters, spell this word backwards, does this rhyme with that), it's not a reasoning failure. It's a tokenization constraint that no amount of compute fixes.

The information was thrown away before the model ever woke up.

Go deeper

Tokenization is step one of the transformer pipeline. If you want the whole stack (embeddings, positional encoding, attention internals (Q/K/V), the feed-forward network, the residual stream, and the next-token loop), 0xkato wrote an excellent from-the-ground-up walkthrough: How LLMs Actually Work. It picks up right where this post leaves off.

Find me on Twitter

Six Lines, Zero API Calls: Running LLMs On-Device in React Native

Vikrant Negi — Mon, 22 Jun 2026 04:49:24 +0000

Every AI feature I've worked on has done the same quiet thing: collect the user's text, send it to someone else's server, pay per token, and pray the network holds. That's fine until it isn't:

Your user is on a flight, with no network and a dead feature.
It's a journaling app, where "we send your private thoughts to a third party" is a hard no.
Finance notices the OpenAI bill climbing in a straight line with usage.

There's another option most React Native devs still treat as exotic: run the model on the device. No API call, no network, no per-token cost. The first time I wired this into an offline text-enhancement tool with Expo, the surprise wasn't that it worked. It's that the actual model code was about six lines. The hard parts were everywhere except the model.

This is a walkthrough of react-native-executorch (by Software Mansion, the Reanimated and Gesture Handler folks), built on Meta's ExecuTorch runtime. We'll build a working local chat screen, but more importantly I'll show you the traps. The ones that cost me an afternoon each. The ones an AI-generated tutorial will confidently get wrong because the API changed underneath it.

software-mansion / react-native-executorch

Declarative way to run AI models in React Native on device, powered by ExecuTorch.

React Native ExecuTorch

React Native ExecuTorch provides a declarative way to run AI models on-device using React Native, powered by ExecuTorch 🚀. It offers out-of-the-box support for a wide range of LLMs, computer vision models, and more. Visit our HuggingFace page to explore these models.

ExecuTorch, developed by Meta, is a novel framework allowing AI model execution on devices like mobile phones or microcontrollers.

React Native ExecuTorch bridges the gap between React Native and native platform capabilities, enabling developers to efficiently run local AI models on mobile devices. This can be achieved without the need for extensive expertise in native programming or machine learning.

Table of Contents

Supported Versions

The minimal supported version are:

iOS…

View on GitHub

The mental model

Before any code, one idea that saves a lot of confusion: the LLM is one part of your app, not the app itself. The library gives you the model and nothing else. Everything around it is still your job.

It helps to picture three things working together:

Your normal app code is predictable. Same input, same output, every time: the buttons, the list, the navigation.
The model is not. Give it the same prompt twice and you'll get slightly different answers, because it generates text by predicting likely next words, not by looking facts up. That's also why it sometimes states wrong things with total confidence. It isn't a defect you can patch, it's how the thing works, so plan for it.
The person reading the output is the final check. They decide what to trust and what to ignore.

react-native-executorch owns only the middle piece. It hands you a stream of words and a few status flags. It does not manage your chat UI, decide when to run the model, or judge whether the answer is any good. Those are yours to build.

Prerequisites

New Architecture only. The library does not support the old RN architecture. If your app is still on it, that's your first migration.
Expo SDK 54+ if you're on Expo (which I'd recommend). Older SDKs break on the file-system APIs the library now depends on.
A custom dev build, not Expo Go. This relies on native modules. Expo Go will not load it. This trips up everyone the first time.
A real iOS device for release builds. Because ExecuTorch runs natively, you can't produce an iOS release build targeting the simulator. Debug on the sim is fine; release testing needs hardware.

That last pair isn't optional advice, it's the difference between "why won't this run" and a working build. Write them on a sticky note.

Setup

Installation is two steps: install the core package, then add a resource fetcher adapter.


npm install react-native-executorch

Then a resource fetcher adapter. These are platform-specific, so install the one that matches your project.


# Expo projects

npm install react-native-executorch-expo-resource-fetcher expo-file-system expo-asset


# Bare React Native

npm install react-native-executorch-bare-resource-fetcher @dr.pogodin/react-native-fs @kesha-antonov/react-native-background-downloader

Before you call any other API, you must initialize ExecuTorch with that adapter, once, at your app's entry point:

// App.tsx (or index.js), top level, runs once

import { initExecutorch } from "react-native-executorch";

import { ExpoResourceFetcher } from "react-native-executorch-expo-resource-fetcher";

initExecutorch({ resourceFetcher: ExpoResourceFetcher });

Skip this and the first model you load throws ResourceFetcherAdapterNotInitialized. It's the most common setup mistake, and an easy one to miss because initExecutorch lives at your entry point, far from where you actually call useLLM.

One more, if you plan to bundle a model with the app via require() instead of downloading it. Add the binary extensions to Metro:

// metro.config.js

defaultConfig.resolver.assetExts.push("pte"); // exported model

defaultConfig.resolver.assetExts.push("bin"); // tokenizer

Loading a model

Here's the whole "load an LLM" surface:

import { models, useLLM } from "react-native-executorch";

function Chat() {
  const llm = useLLM({ model: models.llm.lfm2_5_1_2b_instruct() });

  // ...
}

models.llm.* is a factory of pre-exported, ready-to-run models. One factory call gives the runtime everything it needs, already bundled:

the model itself, in ExecuTorch's .pte format, already converted
the matching tokenizer
the tokenizer config

Software Mansion hosts the full lineup on HuggingFace, so you point at a model and the library handles fetching and wiring up the rest. No manual file juggling.

I'm using LFM2.5 1.2B here because it's the library's own default and small enough to behave on mid-range hardware. You've got real choices though. The bundled lineup includes:

Text models: Qwen 3 (0.6B / 1.7B / 4B), Llama 3.2 (1B / 3B), Phi 4 Mini, SmolLM 2, Hammer 2.1
Vision-capable: Gemma 4 and LFM2.5-VL

Why I'd start small: a 4B model is noticeably smarter and noticeably more likely to crash with an out-of-memory error on a budget Android. Pick the smallest model that clears your quality bar, then size up only if you must.

The hook gives you state to drive your UI:

llm.downloadProgress: 0 to 1 while the model downloads on first launch
llm.isReady: flips true when it's loaded and usable
llm.error: populated if anything blows up
llm.isGenerating: true while tokens are streaming
llm.response: the generated text, updated token by token

Wiring the chat

There are two ways to use this hook, and the docs name them well: functional vs managed. The distinction matters, so don't skim it.

Functional: you own the state

You pass the full message array every time, you keep the history, you get a token stream back. Nothing is remembered for you.

import { models, useLLM, type Message } from "react-native-executorch";

import { View, Text, Button } from "react-native";

function Chat() {
  const llm = useLLM({ model: models.llm.lfm2_5_1_2b_instruct() });

  const handleGenerate = async () => {
    const chat: Message[] = [
      { role: "system", content: "You are a concise, helpful assistant." },

      { role: "user", content: "Explain a closure in one sentence." },
    ];

    // resolves to the full string; llm.response updates live as it streams

    const final = await llm.generate(chat);

    console.log("done:", final);
  };

  if (!llm.isReady) {
    return (
      <Text>Loading model… {Math.round(llm.downloadProgress * 100)}%</Text>
    );
  }

  return (
    <View>
      <Button title="Generate" onPress={handleGenerate} />

      <Text>{llm.response}</Text>
    </View>
  );
}

Note the shape of generate: it both returns a promise and streams into llm.response. So you render llm.response for the live typewriter effect, and await the return value when you need the finished string for, say, saving to a DB. Same call, two consumption patterns.

Managed: the library owns the state

If you're building an actual back-and-forth chat, you don't want to hand-roll the history array. sendMessage plus messageHistory plus configure does it for you:

import { useEffect } from "react";

import { models, useLLM, DEFAULT_SYSTEM_PROMPT } from "react-native-executorch";

function ManagedChat() {
  const llm = useLLM({ model: models.llm.lfm2_5_1_2b_instruct() });

  const { configure } = llm;

  useEffect(() => {
    configure({
      chatConfig: {
        systemPrompt: `${DEFAULT_SYSTEM_PROMPT} Keep answers short.`,
      },

      generationConfig: {
        temperature: 0.7,

        topP: 0.9,
      },
    });
  }, [configure]);

  const send = () => llm.sendMessage("Who are you?");

  return (
    <View>
      {llm.messageHistory.map((m, i) => (
        <Text key={i}>
          {m.role}: {m.content}
        </Text>
      ))}

      <Button title="Send" onPress={send} disabled={!llm.isReady} />
    </View>
  );
}

configure only affects the managed path. chatConfig and toolsConfig do nothing to generate(). That's a subtle footgun: set a system prompt in configure, then call generate and wonder why it's ignored. Mode and config have to match.

My take: use managed for chat, functional for one-shot transforms (summarize this, rewrite that, extract JSON from this). The text-enhancement tool I mentioned was pure functional. There's no conversation, just input string to improved string, and managed state would've been overhead I'd have to fight.

Reality check

This is the section a docs-paraphrase can't write, so here's the honest list of what actually bit me.

1. Dismounting mid-generation crashes the app. Hard crash, not a warning. If the user navigates away while tokens are still streaming, you go down. The fix is to interrupt and wait:

// before unmount / on a stop button

llm.interrupt();

// then wait until llm.isGenerating === false before tearing down

Wire a stop button to interrupt() and gate isGenerating into your navigation guards. I learned this the way everyone does, with a back-button press during a long answer.

2. First launch downloads a model. A big one. These files run from roughly 700MB to over a gigabyte. The hosted models stream down on first use and cache in your app's documents directory, but if you don't render downloadProgress, the user stares at a dead screen and force-quits. Build the loading UX first, not last. And consider letting users pick a model, or bundle a small one for offline-from-install.

3. RAM, not CPU, is your ceiling. Crashes on cheaper devices are almost always out-of-memory, not slowness. Use quantized models. If you're testing on an Android emulator and it dies, bump the emulator's RAM before you blame your code. I wasted real time debugging "my" bug that was just a starved emulator.

4. Expo Go will never work. Said it above, saying it again, because you will forget once and spend ten minutes confused. Native modules mean a custom dev build.

5. One model runner at a time. The architecture is built around a single active model instance. Don't try to stand up two useLLM components side by side and expect both to run.

6. Token batching exists for a reason. A fast model can push 60+ tokens/sec, and if every token triggers a React re-render, your UI jank-fest begins. The library batches token emissions (default around 10 tokens or 80ms, whichever first). If generation feels choppy or your list stutters, tune outputTokenBatchSize and batchTimeInterval in generationConfig rather than reaching for a FlatList rewrite.

Taking it further

Once the basic loop works, the library has more than chat:

Tool calling. Define functions the model can invoke (check weather, toggle a setting, hit a local API). You give it tools plus an executeToolCallback, and in managed mode it parses and runs the calls for you. Use a model whose chat template actually supports it. Hammer 2.1 is purpose-built for function calling.
Structured output. Need clean JSON instead of prose? There's a helper that turns a schema (plain JSON Schema or Zod) into formatting instructions, plus a validator to fix and check the result. This is how you'd build an offline "extract fields from this text" feature.
Vision and audio. Gemma 4 and LFM2.5-VL take a capabilities array and accept an imagePath or audio buffer on sendMessage. On-device OCR into an LLM is a genuinely good offline-translation pattern.
RAG. There's a companion @react-native-rag/executorch package that plugs this LLM (and on-device embeddings) into a vector store for fully local retrieval-augmented generation. If your "model is one component" instinct is itching, that's the package that proves the point.

Next steps

Get the basic loop running, then start making it real. A sensible order:

Validate on real hardware first. Clone the repo, run examples/llm on an actual phone (not the simulator), and watch the first-launch download happen. The number that matters is cold-start time on a mid-range device, and it should drive your model choice more than any benchmark table.
Study a real, shipped app. The minimal example gets you running; a production app shows you the parts the docs skip. Private Mind is Software Mansion's open-source, fully offline AI chatbot built on this library (it's live on the App Store and Play Store). Clone it and poke around: model downloading and management, on-device benchmarking, chat history, and custom assistant presets are all in there to learn from.
Check the benchmark pages before you commit to a model. The docs publish real inference-time, memory, and model-size numbers per model and device. Pick from those, not from vibes.
Build the loading screen before the chat screen. On-device AI lives or dies on that first impression, and it's the one thing the model code can't do for you.
Lazy-load with preventLoad. Every hook takes a preventLoad flag so a model doesn't download or eat RAM until the user actually opens that feature. On a multi-feature app, this is the difference between a 1GB cold install and a fast one.

Once it runs, the fun part is what you build on top. A few possibilities the library makes surprisingly easy:

Hybrid privacy: redact on-device, then go to the cloud. usePrivacyFilter is a local model that finds personal info (names, emails, phone numbers, addresses, even API keys) in text without it ever leaving the phone. Scrub that text locally, then send the safe version to a bigger cloud model. You get GPT-class quality without handing over the sensitive bits.
A fully offline voice assistant. Chain speech-to-text (Whisper is built in), then the LLM, then text-to-speech. Speak, get a spoken answer, no network anywhere in the loop. The library even supports streaming LLM output straight into speech as it generates.
Point-the-camera answers. Run on-device OCR on a photo of a sign, menu, or document, feed the extracted text to the LLM, and you've got an offline translator or document Q&A tool. Like a private, no-signal version of Google Lens.
Answers from the user's own notes. The companion @react-native-rag/executorch package wires the model and on-device embeddings into a local vector store, so the model can answer questions grounded in the user's documents, fully offline.

Each of these is the same core idea pointed at a different problem: the model is one piece, and the product is the experience you wrap around it.

Docs: docs.swmansion.com/react-native-executorch ·
Repo: software-mansion/react-native-executorch

How Graphify Stopped My Team from Burning Thousands of Tokens Per Query

Vikrant Negi — Sun, 21 Jun 2026 11:26:47 +0000

Every time I asked Cursor about our auth flow, it would open 8-12 files, read through each one, and burn through tokens before even starting to answer. For a React Native codebase maintained by 6 developers, this adds up fast.

I lead a front-end team building React Native apps. Cursor is our primary IDE. And while Cursor is great at understanding code, the way it retrieves context — by grepping and reading raw files sequentially — doesn't scale well on larger projects.

Then I found Graphify, and it fundamentally changed how our AI assistant interacts with our codebase.

What Graphify actually does

Before I get to the setup, it's worth understanding the mechanism — because it's not just another Cursor plugin.

Graphify pre-processes your entire project into a knowledge graph. Think of it as a map of your codebase where every function, class, module, and concept becomes a node, and every relationship between them becomes an edge. When Cursor needs to answer a question, instead of reading 47 files to understand a flow, it runs graphify query "auth flow" — a scoped subgraph lookup that returns only the relevant nodes and connections.

The important part: code extraction happens entirely locally via tree-sitter AST parsing. No API calls, no code leaving your machine. You only hit an LLM when processing docs, PDFs, or images. For a pure code project (which most React Native apps are), the extraction cost is basically zero.

The output is three files:

graph.json — the full graph (the core artifact your assistant queries)
graph.html — an interactive visualization you can explore in a browser
GRAPH_REPORT.md — an architecture summary with god nodes, surprising connections, and suggested questions

That report alone is worth the setup. It finds connections between modules you didn't realize existed and surfaces the most-connected concepts in your project — the things everything flows through.

Setting up Graphify for Cursor

I'm on an M1 MacBook Pro. Here's the exact setup that worked for me.

Install

brew install uv  # if you don't have it already
uv tool install graphifyy

Important: use uv tool install, not pip install. On M1 Macs, pip can break Python path resolution because Graphify resolves the Python binary at runtime from a cached path. uv isolates the environment and avoids this entirely. I learned this the hard way.

Build the graph

cd your-project
graphify extract .

First run takes a few minutes depending on codebase size. Since our projects are all code (no PDFs/docs), the entire extraction runs locally on tree-sitter — no API key needed for this step.

Install the Cursor integration

graphify cursor install

This writes a .cursor/rules/graphify.mdc file with alwaysApply: true. If you've worked with Cursor's rule system, you know what this means — it gets injected into every conversation automatically, telling Cursor to prefer graphify query over reading raw source files.

Quick note for anyone working with .mdc files: a rule with alwaysApply: false and no globs and no description will never auto-apply — it becomes manual @-mention only. Graphify sets alwaysApply: true, which is the correct move for a global project context rule.

Set up the git hook

graphify hook install

This installs a post-commit hook. Every time anyone commits, it auto-rebuilds the graph using tree-sitter — fully local, takes seconds. It also sets up a git merge driver so if two devs commit graph updates in parallel, graph.json gets union-merged automatically instead of leaving conflict markers.

After this, you basically forget Graphify is running. The graph stays current with every commit.

Rolling this out to a team

This is where I had the most questions before adopting it, so let me cover the practical stuff.

What to commit

Add these to your repo:

graphify-out/
├── graph.json          # the core artifact
├── graph.html          # interactive visualization
├── GRAPH_REPORT.md     # architecture summary
├── manifest.json       # tracks extracted files (uses relative paths — portable)
└── cache/              # optional — commit for faster rebuilds

.cursor/rules/graphify.mdc    # the Cursor integration rule
.graphifyignore               # if you create one

Add this to .gitignore:

graphify-out/cost.json

cost.json tracks Graphify's own LLM API spend during extraction — not tokens saved in Cursor. It's local accounting, not a shared artifact.

Impact on teammates who don't use Graphify

Zero. This matters — Graphify is purely additive.

The graphify-out/ folder is just inert data files. No build process depends on them, no CI breaks without them. The .mdc file only affects Cursor users who have that rule active. If a dev without Graphify installed triggers the post-commit hook, it fails silently (binary not found) and the commit goes through normally.

You can adopt this incrementally. Install it yourself, commit graphify-out/, and other devs benefit from the graph whenever they install Graphify later. No coordination needed.

Recommended team workflow

Initial setup on main — do the first graphify extract . on main and commit graphify-out/. This becomes the shared baseline everyone pulls.
Feature branches update automatically — the git hook rebuilds incrementally after every commit on any branch.
On merge to main — the graph from the feature branch comes with it. The merge driver handles concurrent updates.

One edge case: if someone runs a long-lived feature branch without the hook installed, their graph.json will drift. A manual graphify extract . --update before raising the MR resyncs it. I've considered adding this to our MR checklist, but honestly the hook handles 99% of cases.

What can go wrong

A few things I ran into or anticipated:

The M1 pip issue. Already mentioned above — use uv tool install, not pip. Wasted about 20 minutes debugging path resolution before figuring this out.

Can you actually measure token savings? Honestly, not directly. Cursor doesn't expose per-conversation token usage. What you can observe: response latency drops (graph queries are faster than multi-file reads), context window pressure reduces (fewer "context limit reached" moments), and Graphify logs every query at ~/.cache/graphify-queries.log with nodes returned and duration — so you get a sense of how targeted the retrieval is.

The rough mental model: without Graphify, Cursor answering "how does auth connect to the API layer?" reads 8-12 files. A typical React Native file is ~200-400 tokens. That's ~3000 tokens just for context loading, before the answer. With Graphify, it reads a scoped subgraph — a fraction of that.

cost.json is not "tokens saved." I initially confused this. cost.json tracks what Graphify itself spent on LLM calls during extraction. For a code-only project, this is near zero. It has nothing to do with what Cursor saves in conversation.

Graph drift on branch switches. If you install the post-commit hook but not the post-checkout hook, switching branches won't rebuild the graph. The latest version of Graphify supports post-checkout hooks too — check if graphify hook install sets both up for you.

What I'd do differently

If I were setting this up again:

Run the initial extraction on a clean main branch first. I initially ran it on a feature branch and had to redo it when I realized the team needed the baseline on main.
Check GRAPH_REPORT.md before sharing with the team. It surfaces god nodes and surprising connections — some of which might reveal architectural issues you'd rather address before making the graph a shared artifact.
Skip committing cache/ initially. It speeds up rebuilds but adds repo size. Start without it and add later if rebuild times become annoying.

Who should use this

Graphify makes the most difference when:

Your codebase has 50+ files and multiple modules that interact
You use Cursor (or Claude Code, Codex, Gemini CLI — it supports 10+ assistants)
You're on a team and tired of your AI assistant not "knowing" the codebase between sessions
You do code reviews and need to quickly understand how a change connects to the rest of the system

For small projects with 5-6 files, the graph adds structural clarity but the token savings are minimal — the files already fit in a context window.

Try it

brew install uv
uv tool install graphifyy
cd your-project
graphify extract .
graphify cursor install  # or the equivalent for your IDE
graphify hook install

That's 5 commands to set up. The graph builds, your assistant starts using it, and the hook keeps it current. No config files to write, no services to run.

Check out the Graphify repo for the full docs. If you're on Cursor specifically, the .mdc integration is the smoothest path — it just works.

If you've been feeling like Cursor "forgets" your codebase every conversation, or burns through context reading files it shouldn't need — Graphify is worth the 10 minutes to set up. It was for me.

I'm a React Native tech lead exploring AI-assisted development workflows. Find me on Twitter and GitHub.

This is how earned money by blogging on Dev

Vikrant Negi — Tue, 30 Jun 2020 11:40:52 +0000

Making money by writing blogs in not new, many people do it for the living. I've also written few paid articles but most of the times, but mostly I write articles for sharing my knowledge, learning new things and help others to learn.

Back Story

Recently, I wrote an article on DEV titled Become a VS Code Ninja with these Extensions and Tools [2020]. The article was very well received in the DEV community and was an overnight success. The article got hundreds of reactions and views within few hours.

Become a VS Code Ninja with these Extensions and Tools [2020]

Vikrant Negi ・ Jun 26 '20

#javascript #beginners #codenewbie #vscode

Here is a screenshot of how many views I've received so far on my post (Jun 26 - Jun 30).

On the next day, I received a mail from uphold about the funds being transferred into my account.

At first, I was surprised since I never thought that I would actually be getting paid for writing on DEV.

Although, the money received was not that much but, the feeling of getting paid and appreciated for your hard work is beyond imagination.

How did I get paid?

Did you know the Dev recently got Web Monetized?

Web Monetization is a standard that provides content creators with an alternative solution to get paid for the content they share on the web. When a user visits a monetized web page, their browser (if it supports Web Monetization) may send micropayments to the site.

Read more about Web Monetization on DEV in following post:

DEV is now Web Monetized

Peter Kim Frank for The DEV Team ・ Jun 10 '20

#webmonetization #gftwhackathon #coil #meta

You can now web-monetize your DEV posts. You will receive micropayments for time spent reading your posts directly. So the more people read your posts the more money you will make.

How do I enable it for my DEV account?

In order to start generating micro-payments with Web Monetization on your DEV content, just following these steps:

Set up a wallet (here are a few options). Dev recommends UpHold.
Once your wallet is set up, you'll receive a Payment Pointer address. If signed up for uphold you can find your Payment Pointer address here
Go to your DEV account settings and add your Payment Pointer to the Web Monetization section
That's it. You'll now receive a micro-payment every time a monetized browsers visit your your profile page and posts.

Read more on how to web-monetize your DEV posts go to the following DEV post:

You can now web-monetize your DEV posts! (But don't get your hopes up too quickly)

Ben Halpern for The DEV Team ・ Jun 10 '20

#webmonetization #gftwhackathon #coil #meta

Future is bright on DEV

Earnings at this point is going to be quite small, but there’s a bright future ahead as more people and platforms begin to adopt this standard. As large percentage of DEV authors will have enabled their own payment pointer, monetized browsers will be able to directly reward their work.

Happy coding! 🙏 and Happy monetizing 🤑

Bonus

Yay!! I received another payment mail from the uphold. 🤑

Follow me on Twitter for more hidden gems @vikrant_negi.

Cover image credit - Photo by Sharon McCutcheon on Unsplash

Become a VS Code Ninja with these Extensions and Tools [2020]

Vikrant Negi — Fri, 26 Jun 2020 19:17:40 +0000

VS Code is undoubtedly the best editor out there especially when it comes to writing javascript. It is fast, feature rich and has huge pool of extensions available which greatly enhances developer experience.

I've been using VS Code for the past 4 years and over these years I came across many these extensions that I would like to share with you. I'm so addicted to these extensions that my developer life would be incomplete without them.

Here is a list of my VS Code extensions:

Moonlight Theme

I've a habit of changing themes quite often and this is the current theme that I'm using these days. Colors are not very light and are easy on eyes both during day and night.

Auto Rename Tag

Automatically rename paired HTML/XML tag, same as Visual Studio IDE does.

Path Intellisense

Visual Studio Code plugin that autocompletes filenames. Very helpful in React projects when importing components from different folders.

SCSS IntelliSense

Advanced autocompletion and refactoring support for SCSS. Must have for front-end developers that use Sass.

Placeholder Images

Generate and insert placeholder images into your HTML. Easy to find placeholders images directly in the VS Code.

Live Server

Launch a development local Server with live reload feature for static & dynamic pages.

Prettier - Code formatter

Code formatter using prettier.

Reactjs code snippets

Code snippets for Reactjs development in ES6 syntax.

Settings Sync

Must have extension in my opinion, it synchronize all your VS Code Settings, Snippets, Themes, File Icons, Launch, Keybindings, Workspaces and Extensions Across Multiple Machines Using GitHub Gist.

Very helpful in case you change your development machine and want to import all your previous VS Code data.

Better Comments

Improve your code commenting by annotating with alert, informational, TODOs, and more!

Bracket Pair Colorizer

A customizable extension for colorizing matching brackets.

Code Spell Checker

If you are like me who can write a single word without mistake this extension is a must have. Checks your code for spell errors and provide suggestions.

ESLint

Integrates ESLint JavaScript into VS Code.

Import Cost

Display import/require package size in the editor.

Quokka.js

Live Scratchpad for JavaScript. Write Javascript and see your outputs in the editor itself. Also has a Interactive Examples which are useful for both experienced developers (as references) and for new developers (to learn).

TabNine

Another must have extension. TabNine is a all-language autocompleter — which uses machine learning to help you write code faster.

This is a Dark Magic extension, after installing and using it for sometime it gives very accurate suggestions which leave you awestruck.

vscode-styled-components

Syntax highlighting and IntelliSense for styled-components.

Visual Studio IntelliCode

The Visual Studio IntelliCode extension provides AI-assisted development features for Python, TypeScript/JavaScript and Java developers in Visual Studio Code, with insights based on understanding your code context combined with machine learning.

Bonus

OpenInCode

📂 Finder toolbar app to open current folder in Visual Studio Code

Closing

I'll keep updating this list with new extensions that I find. Feel free to suggest the extensions that I might have missing. I would love to know what new extensions developers are using.

I've also created a git repo with the VS Code extensions and settings that I frequently use. Find the repo here

Cover image credit - Photo by Ferenc Almasi on Unsplash

Build Facebook-Like Placeholder Loaders in React Native

Vikrant Negi — Thu, 20 Feb 2020 07:07:22 +0000

A good user experience is what separates a awesome app from a regular one. Users expect their apps to be blazing fast since no one enjoys waiting. When building mobile apps, we often use loaders, progress bars, loading indicators to tell users when something is happening or loading.

The latest trend is to show placeholder/skeleton screens as loaders. This pattern of using placeholder improves the user's perceived experience when waiting for something to load. You might have seen these kinds of loaders in apps like Facebook and Netflix.

Loaders in React Native

In most cases, using the good Ol' ActivityIndicator along with React Native modal would suffice. However, as a user and as a developer, I find them to be too mundane and old fashioned.

To make these loaders interesting, I created a React Native package that uses Airbnb's Lottie and Modals to create beautiful animated loaders. If you want to read more more on how to use it read this article.

In this article we will be learn how to implement placeholder screens using rn-placeholder library. We will also use Google Books API to fetch some books data.

Prerequisites

To follow this tutorial, please make sure you have the following installed on your local development environment and have access to the services mentioned below:

Node.js (>=8.x.x) with npm/yarn installed.
expo-cli (>=3.0.4)

Make sure to update expo-cli if you haven't updated in a while since expo releases are quickly out of date.

Getting Started

Let's set up a new Expo project using expo-cli.

$ expo init placeholderLoading

Choose blank template and hit Enter
Then it will ask to name the project, type Placeholder Loading and hit Enter again.
Lastly, it will ask you to press Y to install dependencies with yarn or n to install dependencies with npm. Press y.

This will create a new React Native app using expo-cli.

Running App and Installing Dependencies

Go into the project directory that we just created.

$ cd placeholderLoading

To run the project type:

$ yarn start

Press i to run the iOS Simulator. This will automatically run the iOS Simulator even if it's not opened.

Press a to run the Android Emulator. Note that the emulator must be installed and started already before typing a otherwise it will throw an error in the terminal.

You can also run the app in your device by installing expo app from the app store and then scanning the QR code.

Now, install rn-placeholder and react-native-responsive-dimensions packages

$ yarn add rn-placeholder react-native-responsive-dimensions

The rn-placeholder will help us display some placeholder stuff before rendering our text or media content.
And, react-native-responsive-dimensions will provide us with responsive height and width that automatically adjust themselves based on the screen size of the device.

Creating Components

Now we'll create two components BookCardComponent and BookCardPlaceholderComponent.

Here is the code for BookCardComponent:

const BookCardComponent = props => {
  const { thumbnail, title, authors, onPress } = props;

  return (
    <View style={styles.shadow}>
      <TouchableOpacity
        onPress={onPress}
        style={{
          flexDirection: "row",
          padding: 8
        }}
      >
        <View
          style={{
            flex: 1,
            height: responsiveHeight(16),
            width: responsiveWidth(16),
            marginRight: 10
          }}
        >
          <Image
            source={{ uri: thumbnail }}
            style={{
              borderRadius: 4,
              resizeMode: "contain",
              height: "100%",
              width: "100%"
            }}
            imageStyle={{ borderRadius: 1 }}
          />
        </View>

        <View
          style={{
            flex: 3,
            padding: 5
          }}
        >
          <Text style={{ marginBottom: 5, fontSize: 20 }}>{title}</Text>
          <Text
            style={{ marginBottom: 5 }}
            numberOfLines={1}
            ellipsizeMode="tail"
          >
            by {authors}
          </Text>
        </View>
      </TouchableOpacity>
    </View>
  );
};

Code for BookCardPlaceholderComponent:

const BookCardPlaceholderComponent = () => (
  <Placeholder
    Animation={ShineOverlay}
    style={{
      marginVertical: 6,
      marginHorizontal: 15,
      borderRadius: 4
    }}
    Left={props => (
      <PlaceholderMedia
        style={[
          props.style,
          {
            width: responsiveWidth(22),
            height: responsiveHeight(16)
          }
        ]}
      />
    )}
  >
    <PlaceholderLine style={{ marginTop: responsiveHeight(1) }} width={70} />
    <PlaceholderLine style={{ marginTop: responsiveHeight(1.5) }} width={50} />
    <PlaceholderLine width={50} />
  </Placeholder>
);

The BookCardPlaceholderComponent will be rendered initially until we received data from the Google Books API and after receive data we'll use the BookCardComponent for rendering the books data.

Update App.js

We'll be using React Hooks in this tutorial but you can easily convert it for classes.

Add the following code to your App.js:

export default function App() {
  const [books, setBooks] = useState([...new Array(10).fill({})]);
  const [isDataFetched, setDataFetched] = useState(false);

  useEffect(() => {
    fetch(
      "https://www.googleapis.com/books/v1/volumes/?maxResults=30&q=danbrown"
    )
      .then(response => response.json())
      .then(responseJson => {
        const { items } = responseJson;

        const booksList = items.map(book => {
          const {
            volumeInfo: { title, authors, imageLinks },
            id: bookId
          } = book;

          return {
            bookId,
            thumbnail: imageLinks
              ? imageLinks.thumbnail
              : "https://i.ibb.co/YLC0nQQ/not-found.png",
            title,
            authors: authors ? authors.toString().replace(/,/g, ", ") : "-"
          };
        });

        setBooks(booksList);
        setDataFetched(true);
      })
      .catch(error => {
        console.error(error);
      });
  }, []);

  const renderBookComponent = ({ item }) => {
    const { thumbnail, title, authors, bookId } = item;

    return (
      <BookCardComponent
        key={bookId}
        title={title}
        authors={authors}
        thumbnail={thumbnail}
      />
    );
  };

  const renderX = () => (
    <FlatList
      data={books}
      renderItem={renderBookComponent}
      keyExtractor={item => item.bookId}
    />
  );

  const renderPlaceholders = () =>
    books.map((e, i) => <BookCardPlaceholder key={i} />);

  return (
    <SafeAreaView style={styles.container}>
      {isDataFetched ? renderX() : renderPlaceholders()}
    </SafeAreaView>
  );
}

First, we setup some initial state using useState hook.

const [books, setBooks] = useState([...new Array(10).fill({})]);
const [isDataFetched, setDataFetched] = useState(false);

In books state we'll update all the books that we'll receive from the API and for the initial state we created an array of empty 10 objects.

We also initialized isDataFetched state and set its initial value false. It will be used to track the status of the data received from the API. When we received the data and done with the data manipulation, we'll set its value to true by using setDataFetched.

In the next step, we'll use useEffect hook to call the Google Books API and update our respective states with the data received.

useEffect(() => {
  fetch("https://www.googleapis.com/books/v1/volumes/?maxResults=30&q=danbrown")
    .then(response => response.json())
    .then(responseJson => {
      const { items } = responseJson;

      const booksList = items.map(book => {
        const {
          volumeInfo: { title, authors, imageLinks },
          id: bookId
        } = book;

        return {
          bookId,
          thumbnail: imageLinks
            ? imageLinks.thumbnail
            : "https://i.ibb.co/YLC0nQQ/not-found.png",
          title,
          authors: authors ? authors.toString().replace(/,/g, ", ") : "-"
        };
      });

      setBooks(booksList);
      setDataFetched(true);
    })
    .catch(error => {
      console.error(error);
    });
}, []);

Now, in the return we'll make use of the isDataFetched state to conditionally render the components.

{
  isDataFetched ? renderX() : renderPlaceholders();
}

In renderX() we'll return a FlatList which will render the list of Books using renderBookComponent.

In renderPlaceholders() we'll render BookCardPlaceholder using the map function. This is what the users will see during the data fetching.

So during the data fetching BookCardPlaceholder will be rendered and when the data is fetched successfully BookCardComponent will be rendered by the FlatList.

Here is how the final app looks like:

Conclusion

We have successfully created a React Native app that uses rn-placeholder to show placeholder as loaders during data fetching just like facebook, Netflix and other popular apps.

This is just a simple implementation of placeholders screens as loaders. You can customize these placeholder components according to your need or app theme.

Find the source code in the Github repo here.

Bonus

I've also created a Open source Book Searching React Native app in which I used these placeholder components as loaders. Feel free to have a look at its source code here.

Creating a Multi-Language App in React Native

Vikrant Negi — Mon, 08 Jul 2019 17:12:46 +0000

Language has always been an essential part of any business. As the business grows it becomes important for the business to expand in different countries and regions. To achieve success in these local regions it is important to provide localization.

When it comes to the mobile app, the conditions are no different. As the app users expand to different countries, it becomes important to provide the users with the ability to use the app in their native languages.

In this article, we are going to build a React Native app that supports multi-language using react-native-localize package.

Prerequisites

This tutorial requires basic knowledge of React Native. To set up your development machine, follow the official guide here.

To make sure we are on the same page, following are the versions used in this tutorial -

Node v10.15.0
npm 6.4.1
yarn 1.16.0
react-native 0.59.9
react-native-localize 1.1.3
i18n-js 3.3.0

Getting Started

We'll be building a React Native app which will support English, French and Arabic language.

If you want to have a look at the source code right away, here is the Github link.

To create a new project using react-native-cli, type the following in the terminal:

$ react-native init multiLanguage

$ cd multiLanguage

Add required libraries

Install react-native-localize by typing the following:

$ yarn add react-native-localize

and then link it using:

$ react-native link react-native-localize

If you face any error during installation, check the installation instructions here.

The react-native-localize lib gives you access to a lot of localization related device constants, but does not come with an i18n lib.

We'll use I18n.js to provide a I18n translations on the JavaScript.

$ yarn add i18n-js

Since i18n-js does not seem to provides any cache / memoization we'll use lodash.memoize for the same.

$ yarn add lodash.memoize

Add Translations

Create a translations directory inside src and then create, three JSON files as below for each language.

en.json for English
fr.json for French
ar.json for Arabic

Inside these files will be JSON object with keys and values.

Key will the be same for each language and will be used in the app to display text.

The value will be the actual translation that we want to show to the user and will be different for each language.

For English:

{
  "hello": "Hello World!"
}

For French:

{
  "hello": "Salut le Monde!"
}

For Arabic:

{
  "hello": "أهلاً بالعالم"
}

Similarly, you can add more key-value pairs for every text that will be used in the app.

Add Main Code

Open App.js file and the following imports:

import React from "react";
import * as RNLocalize from "react-native-localize";
import i18n from "i18n-js";
import memoize from "lodash.memoize"; // Use for caching/memoize for better performance

import {
  I18nManager,
  SafeAreaView,
  ScrollView,
  StyleSheet,
  Text,
  View
} from "react-native";

After that, we'll add some helper functions and constants that we'll use later.

const translationGetters = {
  // lazy requires (metro bundler does not support symlinks)
  ar: () => require("./src/translations/ar.json"),
  en: () => require("./src/translations/en.json"),
  fr: () => require("./src/translations/fr.json")
};

const translate = memoize(
  (key, config) => i18n.t(key, config),
  (key, config) => (config ? key + JSON.stringify(config) : key)
);

const setI18nConfig = () => {
  // fallback if no available language fits
  const fallback = { languageTag: "en", isRTL: false };

  const { languageTag, isRTL } =
    RNLocalize.findBestAvailableLanguage(Object.keys(translationGetters)) ||
    fallback;

  // clear translation cache
  translate.cache.clear();
  // update layout direction
  I18nManager.forceRTL(isRTL);
  // set i18n-js config
  i18n.translations = { [languageTag]: translationGetters[languageTag]() };
  i18n.locale = languageTag;
};

Now, we'll create our App class component.

export default class App extends React.Component {
  constructor(props) {
    super(props);
    setI18nConfig(); // set initial config
  }

  componentDidMount() {
    RNLocalize.addEventListener("change", this.handleLocalizationChange);
  }

  componentWillUnmount() {
    RNLocalize.removeEventListener("change", this.handleLocalizationChange);
  }

  handleLocalizationChange = () => {
    setI18nConfig();
    this.forceUpdate();
  };

  render() {
    return (
      <SafeAreaView style={styles.safeArea}>
        <Text style={styles.value}>{translate("hello")}</Text>
      </SafeAreaView>
    );
  }
}

const styles = StyleSheet.create({
  safeArea: {
    backgroundColor: "white",
    flex: 1,
    alignItems: "center",
    justifyContent: "center"
  },
  value: {
    fontSize: 18
  }
});

In our constructor method, we called setI18nConfig() which will set the initial configuration.

Then in componentDidMount() we'll add an event listener which will listen for any changes and call handleLocalizationChange() if any changes occur.

The handleLocalizationChange() method does two things one is that it fires setI18nConfig() and forceUpdate(). This is necessary for Android devices as the component needs to be re-render for the changes to be visible.

We will remove the listener in componentWillUnmount() lifecycle method.

Finally, in render() we'll print out hello by using translate() and passing our key as a parameter into it. It will then automatically figure out the language and the text that needs to be shown for that language.

Running the App

Now its time to see our if the translations are working.

Run your app in simulator or emulator by typing:

$ react-native run-ios

$ react-native run-android

It should be something like this:

Now, change your device language setting to French and open your app again.

Similarly, you can change your language setting to Arabic and see hello in Arabic.

So far so great.

But what happens if I choose some random language whose translation is not added in the app? What language will it fall back to?

Well as it turns out the goal of findBestAvailableLanguage is to return the best available translation. So It will look at your language preference setting to figure out the fallback language.

If you go to the Language & Region setting in your iOS simulator you can see the preference order of the languages.

If the language chosen is not in the preferred language findBestAvailableLanguage returns undefined (so the retained value will be your fallback) because none of the user's preferred languages are available in your translations.

Bonus

The react-native-localize has API that can provides access to lot localization related device constants. Be sure to check out the full APIs available in the docs.

Conclusion

Adding multi-language support is that easy. You can now use react-native-localize to easily provide multiple language support in your app which can help in increasing user's app usage.

Find the source code in the Github repo here.

Originally published on Medium

If you like this article, go ahead and show some love and share.

React Native, Local, Scheduled, Push Notification With Firebase

Vikrant Negi — Thu, 04 Jul 2019 13:30:15 +0000

With ever going increase in app usage, the app developers try to find new ways to keep their user engaged with their apps. Push notifications are one way to keep your users engaged and informed.

Push notifications are the communications channel used by apps to drive user re-engagement and retention. Push notification technology has come a long way from being a single messages delivery system to a rich and interactive medium.

There are two types of notifications, remote and local notifications.

Remote Notifications

With remote notifications, you use one of your company’s servers to push data to user devices via the Apple Push Notification service or FCM.

Local Notifications

Both Android and IOS support the ability to trigger notifications from your application locally. These can either be displayed immediately, or scheduled to be displayed at a later date.

In this article we will be using local notifications feature to send daily a reminder to the user at a particular time every day.

Prerequisites

This tutorial requires basic knowledge of React Native. To set up your development machine, follow the official guide here.

To implement push notifications in React Native application, we are going to use the react-native-firebase.

React Native Firebase has Notifications module that supports for both remote (FCM) and local notifications.

To make sure we are on the same page, the following are the versions used in this tutorial:

Node v10.15.0
npm 6.4.1
yarn 1.16.0
react-native 0.59.9
react-native-firebase 5.2.3

Getting Started

To create a new project using react-native-cli, type the following in terminal:

$ react-native init localReminders

$ cd localReminders

Install React Native Firebase

Install react-native-firebase by following installation instructions here.

Make sure you have completed both iOS and Android setup.

Install Modules

React Native Firebase only provides your application with access to Core features.

To user notification in our react native app, we'll need to also install the Cloud Messaging and Notifications modules.

Install Cloud Messaging by following the instructions here.

Install Notifications by following the instructions here.

Again, make sure you followed the steps for both iOS and Android.

Initial code setup

In your App.js file add these imports:

import React, { Component } from "react";
import { Alert } from "react-native";
import firebase from "react-native-firebase";

import Dashboard from "./src/Dashboard";

Create an empty Dashboard.js file in your src folder. We'll fill this with code in later part of the tutorial.

Now create a class component called App as follow:

export default class App extends Component {
  componentDidMount() {
    // Create notification channel required for Android devices
    this.createNotificationChannel();

    // Ask notification permission and add notification listener
    this.checkPermission();
  }

  createNotificationChannel = () => {};

  checkPermission = async () => {};

  render() {
    return <Dashboard />;
  }
}

We've created a few helper methods in this class component that we called on componentDidMount() lifecycle method. In render, we'll return the Dashboard component.

Let's review and add code to these methods and see what they do and why do we need them.

Create Android Notification Channel

As of Android 8.0 (API Level 26), notifications must specify a Notification Channel or they will not appear.

To allow React Native Firebase to work seamlessly across all versions of Android, you will need to create a channel before you can display a notification. This block of code can be re-run multiple times, so it is safe to do it each time your application starts.

To create this notification channel we created a custom helper method createNotificationChannel(). Update it with the following:

createNotificationChannel = () => {
  // Build a android notification channel
  const channel = new firebase.notifications.Android.Channel(
    "reminder", // channelId
    "Reminders Channel", // channel name
    firebase.notifications.Android.Importance.High // channel importance
  ).setDescription("Used for getting reminder notification"); // channel description

  // Create the android notification channel
  firebase.notifications().android.createChannel(channel);
};

Android channel accept three parameters channelId, name and importance.

For full reference documentation, please see AndroidChannel and AndroidNotifications.

Notification Permission and Listener

Before we can send any notification we need to make sure we have the notification permission and then, when we have that permission we can add a notification listener. This notification listener will listen for any notification and return us with the notification when received.

Update your checkPermission() method with the following:

checkPermission = async () => {
  const enabled = await firebase.messaging().hasPermission();
  if (enabled) {
    // We've the permission
    this.notificationListener = firebase
      .notifications()
      .onNotification(async notification => {
        // Display your notification
        await firebase.notifications().displayNotification(notification);
      });
  } else {
    // user doesn't have permission
    try {
      await firebase.messaging().requestPermission();
    } catch (error) {
      Alert.alert(
        "Unable to access the Notification permission. Please enable the Notification Permission from the settings"
      );
    }
  }
};

When the notification listener receives a notification, we call displayNotification() method with the notification received which will display the notification.

We can now receive and show the notification. Now its time to schedule a local notification which will fire at some point in the future.

Dashboard Screen

We are going to create a Dashboard screen which will have a switch to enable and disable notifications and a time picker to set time to receive notifications. It will look something like below.

To make this UI Screen we'll add few third party helper libraries.

react-native-elements - UI component library
moment - Handling Date Object
react-native-modal-datetime-picker - A React-Native datetime-picker for Android and iOS

Let's start with adding the required imports:

import React, { Component } from "react";
import { Platform, StyleSheet, Text, SafeAreaView, View } from "react-native";
import { ListItem } from "react-native-elements";
import firebase from "react-native-firebase";
import DateTimePicker from "react-native-modal-datetime-picker";
import moment from "moment";

Now we'll create and default export Dashboard class component.

Now, add some local states:

state = {
  enableNotification: true,
  isDateTimePickerVisible: false,
  notificationTime: moment({ hour: 17 })
};

Now we want to set reminder as soon as user lands on the dashboard, so we'll create and call a setReminder() method on componentDidMount() lifecycle method:

componentDidMount() {
  this.setReminder();
}

setReminder = async () => {
  const { notificationTime, enableNotification } = this.state;

  if (enableNotification) {
    // schedule notification
    firebase.notifications().scheduleNotification(this.buildNotification(), {
      fireDate: notificationTime.valueOf(),
      repeatInterval: 'day',
      exact: true,
    });
  } else {
    return false;
  }
};

In setReminder() method first we use notificationTime and enableNotification state.

If enableNotification is true we schedule the notification using scheduleNotification() method.

The scheduleNotification() has two parameters, notification and schedule.

For notification we'll call another custom method buildNotification() which will return notification and, in schedule we'll pass an object with fireDate, repeatInterval and exact keys.

The fireDate is the date when the notification should first be shown, in milliseconds. For repeatInterval we'll use day, as we want the notification to be shown everyday. The exact option is Android only and it denotes if the fireDate should be respected exactly, i.e. for reminders, or if it can deviate slightly to save battery.

In else we'll just return false.

Now, we'll add buildNotification() method which will build a notification when a notification is received:

buildNotification = () => {
  const title = Platform.OS === "android" ? "Daily Reminder" : "";
  const notification = new firebase.notifications.Notification()
    .setNotificationId("1") // Any random ID
    .setTitle(title) // Title of the notification
    .setBody("This is a notification") // body of notification
    .android.setPriority(firebase.notifications.Android.Priority.High) // set priority in Android
    .android.setChannelId("reminder") // should be the same when creating channel for Android
    .android.setAutoCancel(true); // To remove notification when tapped on it

  return notification;
};

Let's add some helper method for the notification switch and time picker. These will be used by their respective components to set local states which will then later be used:

enableNotification = value => {
  this.setState({
    enableNotification: value
  });
};

showDateTimePicker = () => {
  this.setState({ isDateTimePickerVisible: true });
};

hideDateTimePicker = () => {
  this.setState({ isDateTimePickerVisible: false });
};

handleDatePicked = date => {
  this.hideDateTimePicker();

  this.setState({
    notificationTime: moment(date)
  });
};

Finally, the render() which we'll return the UI of the dashboard:

render() {
  const { enableNotification, isDateTimePickerVisible, notificationTime } = this.state;
  return (
    <SafeAreaView style={styles.container}>
      <View style={styles.cardTitleView}>
        <Text style={styles.cardTitle}>Add Reminder</Text>
      </View>
      <ListItem
        title="Notification"
        bottomDivider
        titleStyle={styles.titleStyle}
        switch={{ onValueChange: this.enableNotification, value: enableNotification }}
      />
      <ListItem
        title="Time"
        titleStyle={styles.titleStyle}
        onPress={this.showDateTimePicker}
        rightElement={<Text style={{ opacity: 0.7 }}>{moment(notificationTime).format('LT')}</Text>}
      />
      <DateTimePicker
        isVisible={isDateTimePickerVisible}
        onConfirm={this.handleDatePicked}
        onCancel={this.hideDateTimePicker}
        mode="time" // show only time picker
        is24Hour={false}
        date={new Date(notificationTime)}
        titleIOS="Pick your Notification time"
      />
    </SafeAreaView>
  );
}

Time to sprinkle in some styles to make UI more appealing.

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: "#EEEFF0"
  },
  cardTitleView: {
    paddingHorizontal: 15,
    paddingTop: 15,
    paddingBottom: 8
  },
  cardTitle: {
    fontSize: 15,
    color: "#585858",
    fontWeight: "600"
  },
  titleStyle: {
    fontSize: 20,
    color: "#585858"
  }
});

That's it. We are done with development. In the next section, we'll test it out in an iOS simulator.

Running the app

Test the app by enabling notification and setting time 1 min in the future.

Note: Sometimes the notification may not show at the exact time. Please wait for a whole minute for notification to appear.

Conclusion

We can now schedule daily local push notification in our React Native app for both iOS and Android.

Apart from firebase, there are other libraries you can use to implement local push notification like react-native-push-notification.

Here is the Github repo local-reminders.

Originally published on Medium

PS: Cover image by Jamie Street on Unsplash

React Native Location Tracking

Vikrant Negi — Mon, 21 May 2018 18:09:06 +0000

If you’ve been working with React Native you must have used or heard about react-native-maps. React native maps is a react native package that provide Google Maps API for React Native. Using static google maps is very common but today we are going to use one of the widely used feature of google maps, location tracking using React native.

Find the project repo here

Getting Started

Start by creating a React Native project and name it whatever you want. I’m using the react-native-cli but create-react-native-app should also work just fine.

react-native init locationTracking

Installing react-native-maps

First, download the library from npm:

npm install react-native-maps --save

Installing react-native-maps requires adding code to native iOS and Android files. Follow the installation instructions provided by the react-native-maps. After installation make sure that the project builds successfully before moving forward.

Installing react-native-maps is not a simple task. If you are doing it for the first time I would suggest going through the installation instructions carefully. Believe me this will be the toughest task of this tutorial. Use google if you face any errors.

Using react-native-maps

Great, now that you’ve successfully installed the react-native-maps. Let’s move to the juicy part, where the real magic happens.
Let first set some initial states that will be used for this project.

constructor(props) {
  super(props);
  this.state = {
    latitude: LATITUDE,
    longitude: LONGITUDE,
    routeCoordinates: [],
    distanceTravelled: 0,
    prevLatLng: {},
    coordinate: new AnimatedRegion({
     latitude: LATITUDE,
     longitude: LONGITUDE
    })
  };
}

We’ll use these states later in the app, the only thing of interest here is the new AnimatedRegion which will help us to animate our markers when the location updates.

Watch for location changes

Now we’ll need to get the location coordinates every time the user moves. Google maps geolocation API has watchPosition method which will hep us get the location coordinates whenever they gets changed.

componentDidMount() {
  this.watchID = navigator.geolocation.watchPosition(
    position => {
      const { coordinate, routeCoordinates, distanceTravelled } =   this.state;
      const { latitude, longitude } = position.coords;

      const newCoordinate = {
        latitude,
        longitude
      };
      if (Platform.OS === "android") {
        if (this.marker) {
          this.marker._component.animateMarkerToCoordinate(
            newCoordinate,
            500
          );
         }
       } else {
         coordinate.timing(newCoordinate).start();
       }
       this.setState({
         latitude,
         longitude,
         routeCoordinates: routeCoordinates.concat([newCoordinate]),
         distanceTravelled:
         distanceTravelled + this.calcDistance(newCoordinate),
         prevLatLng: newCoordinate
       });
     },
     error => console.log(error),
     { enableHighAccuracy: true, timeout: 20000, maximumAge: 1000 }
  );
}

The watchPosition gives us the information about user’s location whenever it get’s changed. We then use ES6 Destructuring to get latitude & longitude from the position.coords. Also, we’ll get coordinate, routeCoordinates & distanceTravelled from initial state.

We’ll than create newCoordinate variable that will store these new updated location coordinates that we received from position.coords. Now that we have got the updates coordinates we’ll animate the marker to these new coordinates. Both Android and iOS have different way of handling this so we’ll use Platform Specific Code to handle this.

if (Platform.OS === "android") {
  if (this.marker) {
  this.marker._component.animateMarkerToCoordinate(
    newCoordinate,
    500
   );
  }
} else {
  coordinate.timing(newCoordinate).start();
}

Now its time to update our initial states with the new one.

this.setState({
  latitude,
  longitude,
  routeCoordinates: routeCoordinates.concat([newCoordinate]),
  distanceTravelled: distanceTravelled + this.calcDistance(newCoordinate),
  prevLatLng: newCoordinate
});

Calculating Distance Travelled

We have used distanceTravelled state variable to store the distance travelled by the user. To calculate this distance we’ll create a new function calcDistance that will take newLatLng as parameter and prevLatLng as state variable and will return distance.

calcDistance = newLatLng => {
  const { prevLatLng } = this.state;
  return haversine(prevLatLng, newLatLng) || 0;
};

Looking at this function you maybe wondering when did calculating the distance got so complex. Apparently due to the curvature of the earth calculating distance with the help of latitude and longitude is not so straightforward. Earth has got some curves.

To calculate the distance using latitude and longitude we need to use Haversine formula. If you are like me who struggles with mathematics 😅, there is a hope in the form of a haversine npm package that can help us calculate distance using latitude and longitude. Install haversine npm package using the following command.

npm install haversine

Rendering MapView

Since component need region prop which accepts an object with location coordinates. We are going to create a function that returns all necessary information needed.

getMapRegion = () => ({
  latitude: this.state.latitude,
  longitude: this.state.longitude,
  latitudeDelta: LATITUDE_DELTA,
  longitudeDelta: LONGITUDE_DELTA
});

Now we’ve all the information need to render the map.

<MapView
  style={styles.map}
  showUserLocation
  followUserLocation
  loadingEnabled
  region={this.getMapRegion()}
>
  <Polyline coordinates={this.state.routeCoordinates} strokeWidth={5} />
  <Marker.Animated
    ref={marker => {
      this.marker = marker;
    }}
    coordinate={this.state.coordinate}
  />
</MapView>

We’ve also used the Google Maps Polyline to draw the path as the user moves. Polyline has acoordinate props which accepts an array of coordinates which we can get from our routeCoordinates. We’ve also set the strokeWidth to so we can see the path clearly.

Next to show the Animated marker we’ll use Marker.Animated component to show marker at user current position. It has coordinate props which will get the coordinate object from the state.

Show Distance Travelled

Finally to show the distance travelled by the user we’ll set up a View with the proper styling applied.

<View style={styles.buttonContainer}>
  <TouchableOpacity style={[styles.bubble, styles.button]}>
    <Text style={styles.bottomBarContent}>
      {parseFloat(this.state.distanceTravelled).toFixed(2)} km
    </Text>
  </TouchableOpacity>
</View>

Testing

Now that we’ve all the necessary pieces in place we can finally run our app.

To test the app on iOS simulator we’ll use the location mode available in iOS simulators. After running the app go to Debug > Location > Freeway Drive setting in simulator to turn on this feature. Doing so should result in something similar as below.

For Android, it’s not that straightforward as Android emulators doesn’t have any in built feature to test the dynamic location changes. To test it, either you can manually change your position by walking some distance or you can use 3rd party mock location apps. I was able to test this using GPS Joystick app on Android.

Conclusion

We have successfully created a React Native app that tracks an user location and draws the path. It can also calculate the distance travelled by the user.

I’ve skipped the styles and some other boilerplate code needed for this app but you can find that in the github repo here.

I hope this helps you to understand the Google maps API. Maybe you can take inspiration from this to build something amazing. Please feel free to leave any feedback, I’m always looking for better solutions!

Originally published on Medium