DEV Community: Vikrant Negi

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