Forem: Ponikar

What the heck is OpenClaw/Clawbot/MoltBot?

Ponikar — Wed, 04 Feb 2026 19:24:32 +0000

Why Are AI Agents Suddenly a Big Deal?

Something happened recently in the world of AI agents. All of a sudden, people around me started going crazy about this new AI agent whose name has already changed three times.

But AI agents are not new. They’ve been around for almost three years. So what changed? Why does it suddenly feel like a big deal or even a breakthrough in the era of AI agents?

Let’s break it down.

What Is an AI Agent?

At its core, an AI agent is an LLM that is given a concrete instruction to perform a particular task.

It can reason to make better decisions
It has access to a set of tools to perform actions in the real world
It can operate beyond simple text generation

Enter OpenClaw

OpenClaw (yes, the one that changed its name three times) does something similar — but also a lot more.

First of all, it’s open source, which means anyone can run it locally or on the cloud.

But more importantly, OpenClaw is not just an agent — it’s an agentic system.

Think of it this way:

When LLMs entered the real world, they only had a brain. They could think and respond, but only through text. It always felt like something was missing.

AI agents were supposed to bridge that gap.

OpenClaw is one of the first serious attempts at doing exactly that.

An AI That Has Its Own World

OpenClaw can literally control a computer.

It understands its environment
It can take actions
It can spawn multiple sub-agents to handle complex tasks
It can effectively manage and coordinate those agents

This is why it’s recommended to give OpenClaw an isolated and dedicated environment to do its work.

Yes, you can run it on your own machine — but unless you really know what you’re doing, it’s risky.

Communication: How Do You Talk to It?

Any AI agent needs a way to communicate with humans.

Usually, this is done via a web-based UI. But OpenClaw is designed to run independently and potentially forever.

So instead of a UI, it uses existing messaging platforms like:

Telegram
WhatsApp
Slack

These channels allow you to access the agent from any device. They establish a secure connection so whenever you send a message, the agent acknowledges it, responds, or takes action.

Dashboard

OpenClaw is model-agnostic.

You can configure it to use:

Anthropic models
Google Gemini
Open-source models

You choose whatever works best for your use case.

Agents

When you set up OpenClaw, you start with a single agent that is managed via a gateway.

You can then create multiple specialized agents for specific tasks.

The real beauty of OpenClaw is that these agents can:

Communicate with each other
Assign tasks
Share context

Memory System

OpenClaw has a structured memory system:

AGENTS.md

Operating instructions and additional memory
memory/YYYY-MM-DD.md

Daily append-only logs that capture day-to-day context

(today’s and yesterday’s files are loaded at session start)
MEMORY.md

Curated long-term memory for decisions, preferences, and durable facts
SOUL.md

Defines the agent’s persona, tone, boundaries, and communication style
IDENTITY.md

Specifies the agent’s name, vibe, emoji, and avatar
USER.md

Stores facts about you, including your preferred name and profile details

Skills

Skills are special doors that let the agent interact with the outside world — similar to tools in LLMs.

For example:

Playing your favorite song on Spotify
Calling APIs
Interacting with services

Heartbeat (Cron Jobs)

OpenClaw also supports scheduled tasks using cron-like heartbeats.

Running an agent 24/7 is a bad idea unless you’re doing very intensive work.

Instead:

The agent wakes up at a specific time
Does its job
Goes back to sleep

This approach minimizes compute costs.

If multiple agents are involved, they can coordinate by updating MEMORY.md to assign tasks or share context.

So What’s the Real Breakthrough?

What’s surprising is that OpenClaw isn’t built on some brand-new LLM breakthrough.

It still uses the same class of models that appeared around 2022 — just smarter versions.

The real innovation is not the model, but the system.

OpenClaw is an agentic system that defines a sophisticated way for AI to:

Control its environment
Work autonomously
Coordinate multiple agents
Persist memory and context

Final Thoughts

There’s a lot more that I didn’t cover in this post.

The goal here was to get you familiar with this new agentic system and explain why it’s different from traditional AI agents.

If you have questions or doubts, feel free to leave a comment.

Hope you enjoyed reading this!

Building a performative React Native app

Ponikar — Thu, 08 Jan 2026 18:02:13 +0000

Hi there,

It's 2026 and building an app with React Native could not become more easier. Thanks to the open-source React Native community and Expo ecosystem. In the era of AI, it enables anyone to build an app faster than ever.

However, building a performative React Native app is still challenging. Your MVP might work but not across all the mobile devices.

This blog covers the painful points on how to profile and build a performant React Native app that works smooth as much as possible, even on mid-range Android devices.

Profile

Before you decide to improve performance of your app, let's first understand what part of your app is really slow.

For starters, React Debugger helps a lot to understand things such as expensive re-rendering, initial load time, screen mount/unmount state.

Do not underestimate React Debugger for your React Native app, it can help you a lot to improve the performance.

If you are more curious to profile your app beyond JavaScript, you can try profiling your app natively using Xcode or Android Studio.

You can see things like total memory being taken by your app in order to run it. Memory usage when you load a specific screen and perform certain operations.

Native profiling is optional, can be skipped if your app is not doing resource heavy operations like rendering videos or 3D graphics.

You can use IDEs like Android Studio or Xcode to profile your app natively. By doing so, you will understand the overall memory usage, native memory leaks, and CPU usage. This will give you a clear picture of how your app will work.

At this point, you will have some sort of sense about which part of your app is slow. Now let's talk about what and how to optimise it.

Rendering large list

Rendering list can be quite challenging. For starters, if you have simple items to render, you can use FlatList or FlashList by Shopify. Both are straightforward solutions to render moderate lists.

Problem arises when the item takes time to render. To understand this in a much simpler way, consider each item in the list takes ~400ms. FlatList virtualization concept basically adds/removes items as user scrolls and it is pretty obvious to spot blanks in between the list because the CPU is most of the time busy performing virtualization.

In order to deal with this problem, there are solutions like FlashList which can recycle the item and make sure to reuse it. Another one is LegendList which follows the concept of reactivity and makes sure to not re-render item again if nothing changes.

LegendList is a robust solution for rendering large sets of items efficiently, accurately mitigating blank spaces between list items through precise positioning and optional recycling.

Legend-State pairs naturally with LegendList for scenarios requiring fine-grained reactivity, such as real-time data updates in large, dynamic lists where standard React state might trigger unnecessary re-renders.

Initial boot time

Boot time is the time which requires your app to load and run on the device. This time includes loading and executing JS bundle in the RAM.

As you have guessed it, if your app has a bloated JS bundle, it will take some split seconds to load it and users may feel frustrated waiting for the app to launch.

You can use tools like webpack analyzer to understand which part of your bundle is large enough. You can look for third party dependency which is contributing most to the size and replace it with a lighter one.

Unlike web, React Native out of the box doesn't support code splitting entirely. It's a concept where your JS bundle gets divided into multiple chunks. This way client loads only required JS.

You can use Repack bundler which supports code splitting. It will require additional configuration to make it work.

As a good thumb rule, avoid bundling media assets like images/SVGs along with your business logic. Use remote servers to host and cache it using libraries like expo-image which loads and caches the assets once.

Again, profiling can help you to understand which part of your app is slow at rendering. It can be a particular screen or component of the app which requires more resources.

Illusion of lazy load

Earlier when I was building Huddle01 meet app, we noticed a lag in the Android app. Initially the component was taking time to load. We soon realised we are rendering too many components initially.

Our app has multiple bottom sheets in the meeting room. Initially we decided to render all the sheets at once. Android unlike iOS has limited resources, especially low-mid range Android devices.

Instead of rendering all the bottom sheets at once, we just toggled the sheet, in other words rendering only one sheet at a time. Our Android app became smooth just by applying conditional rendering.

As a rule of thumb, avoid rendering parts of your app which are not visible initially to users. Remember Android devices are resource constrained and cannot optimize it like iOS.

I call this technique an illusion of lazy loading. Use it with caution, you can selectively decide which component to conditionally render.

Optimise this technique with Intersection Observer. This way you completely avoid rendering components which are not visible at the time.

Synthetic sugar trade-offs

Avoid fancy JS libraries which offer nothing but just a fancy way of writing JavaScript. Remember your JS is 80% of your native app so every library you install is liable to performance issues.

Before you install any library, try to use a custom solution if possible. I would even recommend avoiding CSS libraries if you are targeting low-end Android devices.

Although there are lightweight libraries like react-native-unistyle which leverage compile time and avoid runtime overhead.

It's better to measure first before you decide to use any library.

Runtime overhead is the worst for your app.

Do not optimize for an API if you are targeting an audience which prefers using phones around $100.

Imperative way to handle UI changes

You might have heard about a method called setNativeProps, a way to update your UI without triggering render of the React tree. It is very important to use this very carefully because it can lead React state out of sync with the current UI. If re-rendering is becoming very costly then you may consider using this method.

React state triggers re-rendering components and sometimes we may end up rendering whole app. For example dark/light mode. It's pretty obvious since we want all the elements of the app to adapt the mode as soon as possible. If you use React state to manage this, you will see the lag when testing on low-end devices.

Animations

Running animations couldn't be more easier thanks to react-native-reanimated. It leverages UI threads to offload animations but be very careful when working with low-end Android devices.

If your priority is low-end devices, they don't have the luxury of multiple threads and it can backfire. You may see your animations being sluggish, laggy, or not working at all. Yes, this can happen with react-native-reanimated library. Although this may differ from device to device. It's always better to know what your target audience is.

If you are targeting low-end devices, it's better to stick to vanilla React Native animations to avoid randomness.

Leveraging resources like GPU

One of the hacks I found while working with multiple applications is leveraging resources like GPU when possible. While working with React Native we don't have support out of the box, but libraries like react-native-skia are so powerful that they let you use GPU to render graphics from JavaScript.

This feels like magic when your JS code can do realtime image manipulation and apply shaders that run completely on GPU.

There's one more library I would like to point out by Margelo, react-native-filament. This library renders 3D graphics completely on native GPUs. So now it's quite possible to create a Pokemon GO like app in React Native.

It's always better to use powerful libraries like these when possible to avoid overhead on JS threads and leverage device resources.

C++ magic

In recent years, React Native has improved significantly with the new architecture updates that completely get rid of the bridge, enabling access to native APIs from JS runtime using JSI (JavaScript Interface), which is written in C++.

One of the most skilled and talented C++ engineers and core contributor of react native I know, Marc and his team, have published several powerful libraries which leverage JSI modules that are completely written in C++.

For example, react-native-quick-crypto has a C++ implementation which does all the heavy lifting on the C++ side, keeping your JS thread completely non-blocking. C++ as we know is the most powerful and performant language to do all the performance intensive and low-level tasks.

Margelo, founded by Marc, has also released Nitro Modules, a new way of writing native modules which leverage highly optimized JSI and are end-to-end type-safe. You can check the benchmark here.

The reason I am emphasizing more on C++ is because thanks to AI now it's possible to write native modules based on the requirement, and Nitro Modules can help write faster and more robust native modules.

The line between native and JS is getting blurred as we move forward. C++ is bridging that gap and it couldn't be more easier to write your own native implementation which pushes your React Native limits.

Conclusion

Last 5 years were the golden period of React Native. With help of a supportive community, we are getting a truly "write once, run anywhere" codebase. But as we become more creative, we have to push the limit of existing technology. React Native may be limited to some domains but it will improve a lot, or there might be a successor of React Native which truly overcomes all the challenges we are facing now. We may never know but it's so fascinating to see how cross-platform technologies like React Native and Flutter have evolved.

Thanks for reading this blog. Let me know if you have any questions in the comment section.

Happy New Year.

Building React Native app that ship code from Mobile

Ponikar — Sun, 19 Oct 2025 08:05:39 +0000

Ever wondered when there will be a time when you’ll be able to ship code from your mobile? Since LLMs are capable of generating multiple chunks of code, you may not necessarily need your laptop to ship tiny features or hot fixes. What if an AI app could do that for you?

This blog is all about how I am building a mobile AI agent that helps you ship code directly from your phone, and hopefully, you won’t need to open your laptop while enjoying your favorite cocktail on a beach.

Tech Stack

I am using React Native to build a cross-platform app, Cloudflare Workers as a backend, and Vercel AI SDK to set up an AI agentic flow that enables support for multiple LLMs, including Google Gemini, OpenAI, and Claude.

For the sake of the prototype, by default, the AI agent uses Google Gemini Flash 2.0 since it’s a cheaper and effective solution out there.

The workflow

I have named it Gitfix. The code is fully open source, you can check it out here. Basically, it connects with your GitHub account, asks for the required permissions to read repos and raise PRs. Once the AI agent suggests changes, it can automatically raise a PR with a single tap.

So the flow looks like this:

GitHub OAuth flow

Millions of developers use GitHub every day, and it has a rich set of API tools, including GitHub Apps that let developers customize their experience.

As a user, you have to install the Gitfix GitHub app in your GitHub organization. This app will interact with your repos and activities like PRs, issues, etc.

Ultimately, our AI agent takes help from this GitHub app to read and raise PRs.

Our app uses the standard GitHub OAuth flow to authenticate users.

What about privacy?

Our server architecture follows a stateless approach, which means the server doesn’t store any GitHub-related data, including repos, access tokens, or any meta information.

The server relies totally on the client side to provide all the required context that helps the AI agent perform specific operations.

If you haven’t checked the app, you can refer to this tweet example that demonstrates the app flow.

// Detect dark theme var iframe = document.getElementById('tweet-1979579168145961262-772'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1979579168145961262&theme=dark" }

`@<filename>` feature

If you’ve used Cursor’s @filename feature, it’s very handy to let AI know which file to consider and make changes.

I tried to implement a similar behavior in the app. Once GitHub shares meta information about the repo tree and branch data, and when the user mentions that file name, the app simply iterates over the tree data and shows suggestions. Once the user taps on it, the logic simply refers to that file in the prompt.

Each file has a unique sha and filePath that later helps AI fetch the file content. This information is stored on the client side to provide the LLM with file context throughout the conversation.

The AI agent uses these fileRefs to fetch file content using GitHub APIs. Once the contents are ready, we append them to the LLM context so the AI can effectively suggest changes.

Tool calling for rescue

We leverage the LLM’s tool/function calling feature to communicate with external APIs such as GitHub. LLMs can smartly decide which tool to use for a specific operation.

This is the high-level architecture of how the AI agent works. It consists of multiple chains of LLM calls that leverage tool calling to perform certain actions.

The AI agent, at a high level, acts as an orchestrator to decide which route to take based on the user’s query.

High-quality context provides high-quality results

As we all know, the more and better context you provide to LLMs, the more accurate the result you get. Since the server strictly follows a stateless architecture, our app needs to store all the information regarding repos, conversation threads, meta information, file versioning, references, etc.

For example, our app stores file references based on threads. As users use the @fileName feature, the app stores these references corresponding to that thread. When we make a call to the LLM, the app provides these file refs as context.

Incremental changes support

As we all know, LLMs are good at making tiny changes effectively, and we often make iterations of changes from LLMs. The app maintains different versions of files and makes sure to provide the previous iteration of each file.

In summary, the app manages context effectively to help the AI agent generate responses efficiently.

User experience is the ultimate moat you can have in the race of AI wrappers.

The app uses git diff to highlight new changes similar to how GitHub does.

The magical moment

Eventually, once the user is happy with the changes, they can instruct the AI agent to directly raise a PR to their repo.

As you might wonder, the AI agent checks out a new branch, commits changes, and then raises a PR to the main branch. This entire process is hidden behind the abstraction layer provided by the AI agent.

For now, this flow is not very dynamic, it only raises PRs to the main branch, but later, as I continue working on the app, users will be able to decide multiple factors such as branch_name, commit message, and PR description, etc.

Overall, Gitfix is a POC that shows how your mobile can help you ship changes, thanks to the modern era of AI.

It has certain limitations as of now, but the potential is limitless. When Cursor came, it was just an LLM making changes in a bunch of files, but now the agentic flow can do more than what it’s asked for.

Mobile devices are powerful and can even run LLMs locally. This is the beginning of an era where mobile apps can perform intensive tasks with the help of AI.

Thanks for reading this blog. I hope you like it. Let me know your thoughts and questions in the comments.

I’ll see you in another blog. You can reach me on X.

Thanks.

Should You Work at a Startup?

Ponikar — Sat, 20 Sep 2025 08:07:31 +0000

Hi there,

My name is Darshan, a founding engineer. Right now working at Huddle01. If you are hearing this term for the first time, “Founding Engineer” – it is basically an engineer who is a core member of a startup when it was started or a core member of a team when the product is getting built.

This blog is about how it looks like working at a startup. This may help you decide whether you should consider working at a startup or not.

The Odds of Success

It’s risky. Working at a startup is risky. You probably have heard this: “9 out of 10 startups fail” and that is somehow true. But even though it fails, you should aim for learning.

In the early stage of your career, a startup feels like a giant empty canvas where you can experiment, build, and break things. Most importantly, you do this faster.

The Plot

When a startup is yet to figure out product-market fit, all they have is time and budget. Time matters the most, so they tend to work at a higher pace. You have often observed how startups ship faster, ship new updates every week, and sometimes a team is working late at night. (That’s not the case every time, but yeah you gotta.)

The reason why they have to be extremely careful with deadlines is because every startup starts with a foundation idea, and that idea is based on some hypothesis.

A founder or a group of founders needs to test this hypothesis as soon as possible. After all, the users decide whether the startups are onto something or not. So speed matters.

The Swiss Army Knife Engineer

Be ready to do more than just your role. You are not just an engineer but a founding member. Sometimes you will find yourself juggling between product requirements, implementing some analytics tools, working with the marketing team to make tweaks in the product, and it can go on.

When I was working at my first startup job Nintee, I was in the user interview call with my product manager, and we both had to observe user behavior and look for implicit feedback from users.

Either users understood the flow, whether the design was complicated, or which part was high cognitive load for users. We had to take care of all small nuances so we could improve our product.

This is a completely different experience. Like Paul Graham said, “Talk to your users.”

Changes are necessary. You will have times where your founders are gathered around and talking about the learning you had so far, and now in order to move forward, here’s what you as a team have to do.

The Turning Point

Sometimes the initial hypotheses were wrong and the sooner the team realized it, the more you save your time and resources. In this case, you either change the direction of a product. This is known as a pivot. In this process, generally the existing product either gets replaced with something new or you build something on top of it.

So yeah, be ready to throw out your code. As engineers we tend to make things perfect and well-optimized, but in a startup first as a team you gotta make sure you are building the right thing.

A Working Product Over Perfect Code

If you are building something and putting 100% of your efforts into making sure the software is well optimized, but people won’t use it because it’s not making sense for them, it’s useless no matter how awesome it is.

So the first priority of a startup is to make sure they build something that must solve users' problems, and in order to figure this out, the team has to do many experiments. A lot of use-and-throw code is written. User calls happen frequently. The team is looking for a pattern in the analytics dashboard.

So at this point you are not a software engineer anymore but a product engineer who is responsible for the end-to-end process. Unlike MNCs, you are not working in one particular team but you have to collaborate across teams. Startups have a small number of people so it’s very easy to collaborate and you do cross-functional work. That’s the most exciting part.

Hidden Levers

One thing I have noticed and experienced as well is that if you get a chance to work with the smartest and most ambitious people who are shaping the startups, you will realize it eventually shapes you as well.

Your mindset, your growth evolves around it. You are witnessing a kind of history where either you break it or make something happen which has the potential to have a huge impact on thousands of users.

How Startups Create Wealth

Startups can also be the way of creating wealth. The definition of wealth may be different from person to person. Many times people think of wealth as money. Many people get motivated by this. If you are an early member of a team and if you have some equity or stock options, if the company works out, you get rewards for taking risks. You may never work for capital anymore but look for problems that you can solve. But more than just money, you gotta work with a product you genuinely care about. You sometimes find people for life who teach you not just about startups but a general overview of life.

Startups Are Ambiguous

I am not glorifying working at startups, but it’s just very random that unless or until you see it working, it just seems this thing is never going to work out.

Again, startups are risky and you never know where you will be in the next quarter. Things move fast, some startups get shut down, some get acquired, some just change their vision.

So if you are someone who wants to work at a startup, make sure you have some sort of backup, so even if things don’t work out you can prepare yourself for the what comes next.

But risk is worth taking. Youngster have potential and it can only unleash if we work in a challenging environment.

You have to mentally and physically prepare yourself to work at startups. You are going to deal with a large amount of ambiguity and there will be times where you as a person or team will think you are lost and need to figure out where to go next.

Building a resilient attitude will eventually help in the long run.

But this can be a time you will look back and be proud of yourself for the attempt you made.

A Continuous Learning Journey

Learning is the most important part in a startup, either as a person or team. You have to reflect on whatever data you get and you have to work on that. This process is so beautiful and that’s how most startups work.

That’s it for today. That’s my overall thought on startups. If you have any doubts or suggestions about the blog, please feel free to leave a comment.

Thanks for reading.

AI as the Orchestrator

Ponikar — Sun, 15 Jun 2025 14:22:16 +0000

Hi there, my name is Darshan Ponikar. I’m a software engineer transitioning into a product engineer. Recently, I started exploring AI agent use cases, and in this blog, I’m sharing my learnings. These are just my rough thoughts around AI and AI agents.

This is a beginner-friendly blog, but you’re expected to have some understanding of LLMs and a bit of prompt engineering.

The blog aims to draw a general picture of what LLMs with actions look like. Feel free to share your thoughts in the comments and don’t hesitate to disagree with mine.

Rise of AI agents

This is getting more and more clear as AI agents are arising in every possible industry. Any boring task which is important but requires more effort to complete can easily be automated by AI agents.

I am curious to understand how these AI agents work and is that something different or new than LLMs? It's been 5 years since we have LLMs and if you haven’t been active in the space for a while, then you have probably missed the obvious limitation of LLMs where AI cannot take an action.

It still cannot send an email, can write code but cannot run software, can write a blog post but cannot improve SEO — and it goes on.

What LLMs are good at doing is purely text-based, but it's been also quite a while where developers trick LLMs to generate a proper JSON schema for their requirements, and it has improved a lot in recent years.

But generating JSON schema won’t help you much to perform any task which requires more than that.

Beyond prompt engineering

LLMs are generally good at instructing well. You probably have noticed this, but what if they have some sort of way to call some third-party APIs to complete a task?

For example, a way to store data in a DB API?

This is known as tool calling, and it’s evolving a lot.

The idea is that you instruct LLMs and give them a set of tools, each with a unique description. What LLMs do is they basically decide which tool and when to use it in order to fulfil the user's query.

image source

This is more like orchestration of tools, and AI has tools to make decisions in real time that basically changes everything.

Instead of giving some sort of JSON, AI can literally make an API call or pull data from a database. You just have to give them clear instructions on what this tool wants as parameters.

Tool calling on scale

I think on a scale, that’s what LLMs are going to do. They are trained on a very high-quality large dataset and they have some sort of reasoning (let’s assume they have) to make decisions.

Even though they are good at reasoning and decision-making, they don’t have a way to perform actions, and I think we are very far from that future (yet) where LLMs can perform any task.

But they are good at instructing well. They can instruct an AI agent what and how to do. That’s where LLMs are going to take actions through AI agents.

LLMs will operate robots, LLMs are operating third-party software through AI agents.

Next gen wrapper

Think AI agents are like another wrapper around AI, but this time you are providing tools along with instructions so LLMs can almost perform certain actions for a given query.

The complexity of a tool can vary based on the task it is given to perform.

It can be easier to make an API call to something more complex like ordering food online where it has to take care of things like payment, restaurant availability, distance, source to destination, etc.

Obviously, you should start with something simpler first before you make it a little complex.

In general, tools can make different API calls, can use LLMs to reason better, etc.

To make this more standardized, Anthropic came up with MCP server, a standard way to provide third-party API support to LLMs.

Think like how your client app makes an API call to a server via REST APIs metaphorically speaking, MCP server provides REST API to LLMs.

MCP server provides scale so you can make your AI agent as generic as possible based on your requirement.

Since this topic is pretty novice, we don't have many resources available as MCP servers but we are still early for this.

I think it's far easier to just provide tool calling instead of setting up your own MCP server if you just want to test it out.

But in future, we will probably see companies providing MCP servers to communicate, and there might be a startup which solely provides MCP servers for context.

Think like MCP servers for legals, MCP servers to restaurant chains, MCP servers to know your Instagram stats, etc.

But LLMs need to be smarter and efficient enough to make a decision for tool calling, otherwise it won’t make any sense.

Hence the title AI as an orchestration. We are still new, and it’s fascinating to explore endless opportunities that can be fulfilled by AI.

We have an MCP server now. Maybe in the future we will have some other tool to make it more efficient.

Thanks for reading, share your thoughts in the comments section.

OTA updates in React Native

Ponikar — Sun, 14 Jul 2024 14:50:50 +0000

Hi there, it's been a long time since I have written a blog on React Native. Today I just want to explain what OTA updates are and how you can use them in your React Native project.

We will deep dive into OTA updates, advantages, and challenges you may face while dealing with this.

Disclaimer

This blog covers some advanced topics from my experience building various apps. If you're new to React Native, some parts might be hard to understand, and that's okay. Everyone starts somewhere. Feel free to ask questions or share your thoughts in the comments section.

The idea of this blog is to give you a high-level overview of how OTA updates work in the real world. Instead of covering obvious topics like installation and troubleshooting, I'll focus on helping you understand the real impact of OTA updates when working with a production app.

What is OTA update?

OTA stands for Over the Air updates, it's an idea to update your JavaScript bundle on the fly without the need to update the binary (native Android/iOS update).

Basically, if you have OTA updates configured and you push a new bundle, existing users can download and load the new JS bundle on the next boot-up.

OTA updates are really helpful to fix UI-related bugs on the fly and sometimes it helps avoid submitting your apps for review which can take up to 7 days.

There is also one popular method known as Server Driven UI that lets you control the behavior of the UI from the server. OTAs and Server Driven UI are two separate things. I might write a blog on it in the future but this blog is dedicated to OTA updates. You can share your thoughts in the comment section.

So now we have understood what OTA updates are in general. Let's understand how it works in React Native.

In very simple words, OTAs are just for updating your JS bundle on the fly. Roughly speaking, it's just an API call to your server and asking if there has been any update pushed lately or not. The server might give you a JS bundle that you can swap out with the current bundle and load the app, but as you can see things start to get complicated as we speak about swapping the JS bundle and making a server call and loading the JS bundle in the next boot-up.

To make it easier, there are libraries like react-native-codepush and eas-updates by Expo that simplify this process.

These libraries act as a wrapper around your app and they also provide a CodePush server in which you can configure and push your JS bundle.

You can refer to their documentation to install this library. If you are facing any issues, you can share them in the comment section.

Too Easy to break UX

Remember CodePush only updates your JavaScript code. It cannot update your native Java/Objective C code. So it's really easy to break things by accidentally pushing a JS bundle that can break your app if the native modules of that bundle are missing.

Let's take an example, suppose you have a music app live in the app store and people are loving it. They are using it all day but now you have a product requirement that requires you to access the user's microphone. You decided to install a library that lets you access the microphone. This library also requires you to configure native files such as MainApplication.java or Appdelegate.m.

You made changes, everything is working locally as expected. You decided to release this update via CodePush. The moment you release the OTA update the app will crash because your JS code is trying to call a native module which is missing. Users have to reinstall the application and you have to immediately revert that bundle so other users won't experience these crashes.

We had the exact same situation while building Nintee Application. We had to revert the JS bundle and ask users to reinstall the app. It's easy to spoil the UX.

Another challenging part is OTA updates don't reflect immediately. First, the user needs to download the bundle in the background and load it which can happen in the next app boot.

So if users install this app, chances are they can load the stale JS bundle which is locally present. UX can easily get out of sync.

Ground rules

You have to establish some ground rules when you are working with OTA updates.

Stick to the app version: I made a habit to increment the app version whenever I modified any native code. You can easily differentiate and upload the JS bundle corresponding to the app version.

For example,
if Segment A is using version 1.5.2 you can push OTA updates specifically for this segment. This way you can make sure that OTA updates support that App binary and it won't break the app.

Decide whether you want updates to be visible immediately. Prioritize between OTA and Native binary release. You can also ship both updates at the same time.

This makes sure if new users are onboarding, they will see the new changes meanwhile existing users can either load JS on the fly or update the binary.

What's my take on OTA updates?

These are the technical decisions to make sure the user's UX stays consistent.

It depends on your team, and the size of your user base to decide whether you should configure OTA in your app or not.

While working at Nintee, we realized that almost 75% of our users don't bother to update the app. They would likely use the old version of the app if there are no major updates. We had a situation where we had to ask users to update the app. This process became cumbersome as we were onboarding more and more users.

OTA updates help us to push bug fixes, UI improvements, and functionalities on the fly. It was almost like how we update our web applications.

Since the app distribution platform like Play Store and App Store can take up to 24 hours (sometimes) when an app only contains some bug fixes and minor changes, it is a really frustrating experience for a developer.

You just have to be more careful while working with OTA updates as we saw it's too easy to spoil the User Experience.

I hope this blog helped you to understand the high-level overview of how OTA updates work at the production level.

Thank you for reading this blog and I shall come with another exciting blog. Please share your thoughts in the comment section.

Curious to know more? Check out reference links

React Native Code Push library

Expo eas updates

Manage runtime version with eas updates

Microsoft App Center retiring

Happy Hacking...

We love building Cross Platform App!

Ponikar — Sun, 10 Mar 2024 08:02:44 +0000

TL;DR

This article is very generic. I am not going to talk about any specific solution like React Native; rather, I will share my thoughts around the idea of a cross-platform solution. The trap of options and how to decide what to pick for your next MVP/Side project/Product.

The Plot

Imagine you are in 2012, a brand new iPhone 5 came, and Steve Jobs unveiled its revolutionary features. Everyone is excited to use this iPhone, and as a developer, you are eager to build native apps. You learned about XCode, installed it on a Mac, and started learning Objective C to build your first HelloWorld app. Life was pretty simple, right?

Now let's come back to the present; it's 2024, and now we have more than an adequate amount of options to build Native Apps. React Native, Flutter, Ionic, Capacitor, and etc.

All these technologies seem promising, and you are confused about picking from them because you don't want to end up choosing the wrong tool to build your product.

But the idea of cross-platform engineering is that as a developer, while building a product, you spend less time taking care of each platform separately and more time building logic for your business.

But we often find ourselves debating over these existing solutions and wind up doing nothing.

Picking the Tool that works for you

It's not about what is working for others but you.

If you are good at, let's say, Flutter, you should continue upscaling around it and eager to learn more about it.

In the software industry, everything changes rapidly. You never know; maybe the time I am writing this article. There are some nerds writing another JavaScript framework.

Nothing seems to be perfect

Every solution claims to solve certain problems, but it also has certain cons. So eventually, it's on you what to choose.

Let's understand via an example.

React Native renders UI natively, so your end-users likely can't find the difference while using the app. But at the same time, due to the async nature of it, sometimes it's limited, but it has come a long way with a new architecture.

Flutter, on the other hand, renders UI components on canvas, which is faster, but it doesn't render native UI components.

So what to pick?

Seeking for Job opportunities

As someone who is looking forward to building his/her career around this, you should always look at the number of jobs available. Let's take a step back and think which can help you in the long run.

The idea is not marrying a particular technology but being willing to give yourself a chance to explore something new.

In simple words, explore things and decide who is the best for your career and keep accumulating.

Building a Product

In my previous experiences of building a top-notch product, I realize it's a long-term process (feel free to disagree). You start with an MVP, and it's likely to be thrown out if it didn't work.

In this situation, you can be okay to pick anything you like. The idea is to build something faster so you can validate and iterate over it.

So be it anything.

Don't be in dilemma

If it's working for you than it doesn't matter whether it worked for others. At certain points, you may have to switch even multiple times, and that's totally fine. You have to start from somewhere and move faster so you can decide what is working for you.

Lastly, I would say technologies come and go, but the low-level mental model of yours stays the same so focusing on building a great understanding around cross-platform engineering will help you in the long run rather than juggling between what to pick.

If something makes you curious, it's a good thing, and you should iterate over it.

Thanks for reading this article; I just wanted to share my thoughts that worked for me. I hope you have gotten some sense out of it. If you have any questions/suggestions, please feel free to leave your thoughts in the comment sections.

You can reach out to me via X iponikar

Have a great time :)

0 to 1, working in a startup as Software Engineer

Ponikar — Sun, 03 Dec 2023 19:32:18 +0000

It's been a while since I last wrote a blog. I typically cover topics related to the frontend ecosystem, including JavaScript, TypeScript, React, and React Native. This time around, I want to share my personal journey and dive into the world of shipping cool things.

Quick Note

Thanks for taking the time to read this blog. Everything I share here is 100% my thoughts and beliefs. It's based on my experiences, so feel free to disagree or drop your thoughts in the comments. Enjoy the read! :)

TL;DR

This blog recounts my experiences working at an early-stage startup. I've been a Software Engineer at Nintee for over 3 months now, and in this blog, I share my insights and reflections on this period. I hope it helps you decide whether working in a startup is something you'd consider and provides a glimpse into the workings of early-stage startups.

The Plot

I worked as a software engineer at Geekyants from Oct 2021. It was where I began my corporate journey, shipping my first line of code. Working at GeekyAnts was a fantastic experience with amazing community support, providing opportunities to learn something new almost every single day. Things were going well. In the second quarter of 2023, I started feeling the need to shift my focus to building products alongside writing code. I wanted to experience how the product cycle works and how decisions are made.

I believed startups were a great way to learn about this, so I decided to make the switch and join a startup where I could take full responsibility for building something meaningful in a product that adds value to people's lives.

Turn of events

2023 was a tough time, with news of layoffs circulating online. I kept job hunting but wasn't actively looking for a switch since the market was unpredictable. One day, while randomly scrolling through Twitter, I saw a tweet mentioning, "If anyone is hiring for React Native roles, please comment below." I noticed Paras Chopra's reply with a Google Doc link, filled out the form, and within a week, I got a call from the company. The interview process lasted for three weeks.

I know some of you may be interested in the interview process. Let's discuss it on some other day. I promise I will share it soon. :)

I cracked the interview and got a job offer. I was a little confused in this unpredictable market, wondering if I should even consider working in startups. I talked with my friends; the offer was good, but I had no idea about the company and the founder.

These are some points that I considered before joining Nintee.

Founder: As a core member of a team, you always bet on the founder, even if you believe in the idea as much as a founder does. The founder decides where we should head, and as a contributor in the initial days, the founder does the same to you. Since you are going to contribute heavily in the initial days, I realized Paras (Founder of Nintee) is an amazing human being. He often shares his wisdom on Twitter, and he has already built a bootstrap company, Wingify.
Funding: This is a subjective topic. If you are joining a startup that does have funding and has at least 1-2 years of runway, then that's a really good place to start working. On the other hand, initially, when they don't have funding and whether they want to build a bootstrap startup or are looking for funding, it's important to consider how they are going to survive until they reach the point of a little push up. After knowing the wonderful history of Paras, I did not consider funding as an important factor, but Nintee recently raised a seed funding round by Sequoia Capital.
Team: This is the most important factor, and you should take this seriously. As your team is going to be small, you are going to work very closely. Hence, it becomes important to feel comfortable around them, to not hesitate to share your opinion, and to be honest with the team. As a core member of the team, your contribution will shape the product somehow, whether you are honest with the team or not.

Validate Idea

I simply asked one question to Paras, "So are we going to build an MVP, right?" He said no. He said we already have an MVP in a Discord server. I was a little shocked here. I was like, how is it possible to validate an idea without building a prototype of an app or web app. I was wrong. It turned out he did a pretty good job in the Discord server, and people were/still are using the Discord server. Soon, I realized this is the place I was looking for to work. I joined the company in the first week of September 2023.

SDE to Founding Engineer

I got the role of Senior Software Engineer, and my primary goal is to build a mobile application for Nintee. I am not going to talk about what Nintee is; I think our homepage probably justifies that. One thing I'm excited about working here is that if this works, we can make an impact on a huge number of people out there, helping them live a better life. This would be a moment of feeling proud and it keeps me motivated to work.

We are a very small team at Nintee. In the engineering department, we have a total of 6 people, including CTO Abhinav Saxena, who is my manager. We work remotely, and since the team is small, we work very closely with each other. The brainstorming sessions are quite helpful to learn and build as a team. Fortunately, I have a manager who is really talented, and he has amazing work experience like building the messaging app Hike from scratch. Remember Hike? A messaging app that was popular in genZ back in 2016. He keeps sharing his work experience with us, which keeps us inspired to work.

Since the team is small, the feedback loop is fast. We have 1:1 sessions twice a month, in which we share feedback and talk about personal and company growth. I feel very fortunate to work with someone like Abhinav.

Thinking about Product

Technically, it was sorted. We are having a good time building an app. We face obstacles often, but we always come up with solutions. As I said earlier, it's been more than 3 months, and our shipping cycle keeps iterating. One thumb rule of a startup is that feedback shapes products. In order to keep iterating on that feedback, we started shipping faster. We aimed to make two production releases every week. One will have a major features update, and the second one contains bug fixes.

Here's the catch: we don't always make 2 releases a week, but most of the time we did two releases. We started inviting external users and onboarded them via video call. Users are kind enough to give us honest brutal feedback. Their support helps the product a lot to shape the product in the initial stage. I felt astounding knowing that there are people out there who want to try something new and are ready to give feedback.

Move Fast, Break Things

When you don't know whether the idea is going to be a product-market fit, you have to do lots of experiments. The faster this iteration loop, the closer you come to the idea of a product-market fit. Most decisions, whether related to engineering or product, are done very quickly.

In 3 months, we moved things quickly – introducing a UI library, shipping new features, bug fixing, and inviting external users to use our app. Sometimes I refuse to believe we made this much progress so far. There is a time where you may need to redo things, and that's a really common thing.

I personally consider not falling in love with my work unless it's useful to others.

Work-life Balance

As I said earlier, I work remotely. This means I have total control of my time. This is a myth that startups don't have work-life balance unless you don't know what you are doing in your job. I too agree that sometimes we need to pull up our socks and start working hard, but that's not the case often. This is a thrilling time when most startups are about to ship something exciting they've been working really hard on.

If you are a really good developer and you know what you are doing, then building features won't take much time. It's more about understanding what you are building, finding edge cases.

You have to take full responsibility for that feature. You have the control to make decisions in your domain. There's a new term in the market, "Product Engineer," and most of the time you have to act like a Product Engineer.

On the other hand, I never worked in an office. Although we did 10 days of co-working together, and that was also a good time. We found ourselves productive. I am not against working in an office, but since I have spent most of my time working remotely, I feel that it's more productive.

It worked for me, but it may not work for you. So feel free to disagree.

That's the summary of pretty much how my life took turns in 2023. I feel very proud of the decisions that I took in my past. If I did not open Twitter, my life would have been completely different that I can't even imagine.

There is a famous quote, "You are an average of five people you hang out with." I feel very fortunate that I am working with folks who are extraordinarily talented, whose wisdom shapes me somehow. These things only happen when you work at startups.

I will finish this blog with one quote by me:

"Working in a startup is like gambling, either you fly so high or you fall down really fast, but you shouldn't forget you can retry anytime."

Thank you for reading this blog. You can share your thoughts in the comment sections. I will see you with another blog.

React Native is Multi Threaded

Ponikar — Sun, 04 Jun 2023 10:03:58 +0000

TL;DR: React Native is multi-threaded!

Disclaimer

This blog represents my personal thoughts and ideas for achieving exceptional performance in React Native. While it's meant to inspire and explore new possibilities, please remember that the techniques discussed may not work for everyone or in every situation. Let's keep an open and respectful dialogue, and feel free to share your thoughts and questions as we delve into the realm of pushing performance limits in React Native.

Cue

What if I told this to someone suffering from performance issues while building a React Native app? They'd probably troll me in the comment section, and I can't blame them. But before you jump to conclusions, give me 2 minutes to explain why I believe React Native is multi-threaded.

Before we delve into that, I want to address all readers, whether you've been developing React Native apps for a long time or are just starting out. We're at the beginning of the Era of React Native, and things are changing with the introduction of the new architecture called JSI that powers React Native apps. But I won't go into much detail about JSI here; there are good talks and blogs available for that.

Mobile Apps 📱

At the end of the day, we're building native mobile apps. JavaScript acts as the controller. If we look at it broadly, we have two threads, as mentioned in the React Native blog.

UI/Native Thread
JS Thread

The native thread executes the native iOS/Java code, while the JS code runs in the JS thread. As React Native developers, we often interact with the JS thread because we primarily know JS and don't have much knowledge of the native languages, such as Java/Kotlin and Objective-C/Swift.

Think of it as multiple universes. We know that another universe exists, but we have no idea how to communicate with it. The old bridge simply sends data between the JS thread and the native thread, with the JS thread not interacting much with the native thread.

JavaScript is Single Threaded

JavaScript is designed to execute one thing at a time. It can't run multiple code executions simultaneously, effectively blocking the entire JS thread. Consequently, apps become unresponsive.

Solution

React Native wizards identified this problem and realised that expensive tasks like animations can't run on the JS thread. It would be awesome if we could run animations on the native thread and free up the JS thread as much as possible. This led to the development of React Native Reanimated 2. I want to give a shoutout to Swmansion, the company behind this library, as most React Native apps now use it for animations.

Secret Sauce 🍝

The idea is simple: if you want to make React Native apps faster, keep the JS thread as free as possible. But how? Readers might think, "Do you want us to write platform-specific code now because JS can't handle heavy tasks?" Well, no.

By using libraries like Reanimated, React Native MMKV, and React Native Skia, you leverage the native thread. However, I know there are developers building amazing things who think outside the box. I'm always thrilled when I read engineering blogs from companies like Netflix, Meta, and Shopify. They create solutions beyond the limits.

So, for that extra momentum, you might consider writing your own solution in native code to make your app stand out. You need to sit with your team and make important decisions. In this AI era, writing and understanding boilerplate code couldn't be easier, thanks to ChatGPT.

I understand that in 90% of cases, you won't want to choose this path. However, if you really want to write native code for your requirements, here's what you can do:

Write the implementation in Native language.
Create a JSI binding that connects this native method to JS code.
Call this method from JS (Async/Sync).

This is how you can offload your JS thread and make your app blazingly fast.

Final Thoughts 🎁

I know this solution is challenging and may not be for everyone, especially those who are just starting with
React Native. Unfortunately, there is no declarative way to offload your JavaScript thread in React Native. But the future is bright, and we will have support for offloading the JS thread.

Actually, there is a solution. React Native Reanimated has something called a worklet, which runs JS code in the UI thread. However, you need to be very careful when using this. I will provide the documentation link here.

As I mentioned before, this is a new era of React Native, and things will get a lot better in the near future. If you're a beginner, keep doing what you're doing, try to understand how React Native works, and stay aware of what's happening in the React Native world. The best way to do this is by watching RN talks, reading blogs, and engaging with the community.

That's it from my side. Thank you so much for reading the blog. If you have any questions, please put them in the comment section.

I will see you in the brand new blog. Stay tuned.

Darshan Ponikar
Signing off...

Edited by ChatGPT

My React Native Journey

Ponikar — Fri, 25 Nov 2022 11:10:33 +0000

Hi there, My name is Darshan. I work as a Full Stack Engineer and today I want to share my journey with React Native. This blog contains everything I have learned and experienced with React Native.

I bet it excites every react developer out there when first time they get to know about react native. We can finally write native application in JavaScript. So we spin up our machine create a fresh project and start writing our app.

Think like Mobile Engineer

It's okay if the subtitle didn't make sense to you right now. I can understand we have background of web engineer. We don't know anything about mobile engineering and that's totally okay.

In my early day and even today I use to observe a lot of native applications and I compare them with my project and I try to figure out how can I improve my application with that.

Let's suppose you are building a chat app, you can take a reference from WhatsApp or Instagram messaging. Try to figure out what things are need to be added or improved. We will take more about this later in this blog.

Avoid over comparing.

This was my problem. I used to over compare a lot and it made me sad.😅 Lots of time I wanted to quit my project and do something else.

But that's totally okay if you can't reach the perfection in one go. It will come in iteration of versions. Don't put too much stress on yourself.

Expo to the moon 🚀

If you are just getting started with React Native. You don't want to juggle with all the native side configuration and language. Expo is probably a safe option to get started it.

Spend sometimes with Native Environment

It was 50% lie when someone told you that you only have to deal with JavaScript. Sometimes you need to configure native environment to make a feature work. You may have encountered with library which need native configuration.

So it would be good if you get used to it as early as possible. It will definitely going to help you in long run.

User experience matter the most

It's okay if your app UI doesn't look good but I think as Mobile engineer (I hope you are thinking yourself as same 😅)
You should always try to improve the user experience that's the reason users prefers Native apps over Web app.

Take an example of Forms. Forms behaves differently on Native Applications.

Accessibility of Keyboard: When the keyboard shows up the field should be moved up and have enough space between the keyboard and field so users can see whatever they are typing. (Common sense right 😅) In mobile we need to take care of this things explicitly.

Feedback: Users loves to see what happens when they do some interactions with your applications. For example showing loading indicators, Showing Popups, etc.

It should work without Internet

If your application is not working without internet, It won't make sense to install it at first place. You should always integrate offline storage in your app. when users close your app and come back your app should resume from the last state.

You should give a feedback when the app is online/offline. So users are aware of what is happening in background.

Even though you are making a basic app like TodoList. This will make good impression on users.

Performance

Although this section could have covered in User experience section but as we are taking about React Native I want to briefly share my thoughts about it.

You must have heard, when it comes to performance, react native may not a good to build an app. This is totally wrong and this specifically depends on the use case of the application. There are plenty of blogs and talks which justify when to use react native. So I am not going to write anything about it but React Native performs well and there are plenty of good companies even MNCs are investing in React Native so we don't need to worry about that part.

Also React Native is changing, They have recently announced the new architecture that's basically changes the communication part of React Native. (You can read more about it here). Future of react native is far better.

Always start with android.

If you are targeting both platform, focus more on android. iOS has blazingly fast CPU processing power so you might or might not see the performance bottlenecks.

Test your application in low-end devices and make sure everything is working as expected. You may need to invest more time.

Like any react web applications, Avoid unnecessary re-rendering. You can profile your application and figure about which component is causing re-rendering.

You can use debugging tools like flipper to debug better. It has plugin support so you can install or make plugin. That will make our life easier.

Keep Building Stuff

Lastly, I would recommend keep building stuff whether it is clone app or your idea unless you don't build it by yourself you will not understand. Avoid tutorials hell.

I know this blog was very general after all it was my experience with mobile engineering with react native.

Thanks for reading, I hope this blog has helped you. If you are having any questions related to this blog or react native you can put those in a comment box.

All the best. ✨
DM me at iponikar

TypeScript: Types of Types

Ponikar — Sun, 09 Jan 2022 11:29:39 +0000

Hey there, I hope you are doing great! This is my third post about typescript and this is one of the most important topic to discuss.

Hold on

Before you go ahead I am assuming that you have basic knowledge of what is typescript and how does it works but if you don't have any idea about typescript than you can checkout my other blogs.

Introduction to TypeScript

Ponikar ・ Jun 21 '21

#javascript #typescript #beginners #react

TypeScript: Any | Unknown | Never

Ponikar ・ Sep 4 '21

#typescript #javascript #webdev

How to read this blog?

This blog is more like Crash Blog.😂

I have wrote this blog along with examples. Unfortunately I cannot add Interactive code snippets like CodeSandBox.

My advice is to visit this playground and experiment these examples by your own. This will give you good understanding about Typescript.

Let's go........

Quick recap of `Types` and `Interface`

Although typescript gives you default type annotations like string,number,boolean, etc. You may need to create your own types according to your need or when you are working with real world project.

type and interface let you create your own type. So you can use it anywhere in your project.

As I promised everything is driven by examples. Let's see.

Suppose I want to create a User type that contains some properties like name, email, contactNumber etc.

User type with interface


interface User {
   name: string; 
   email: string;
   contactNumber: string;
}

Taddda! We have create our first type. You may say that this is something like creating an object. You are slightly right. This is more like creating user-defined type than object.

User type with type

 type User = {
   name: string; 
   email: string;
   contactNumber: string;
}

You may notice that the both ways of defining type are almost similar. So when should I use which one?

There is one major difference between these two is that interface let you inherit another interface like a One class can inherit another class.

interface A {}

// B can access all the types of A.
interface B extends A {}

If you facing situation something like this. Feel free to use
interfaces.

What is types of types?

If you are using typescript, there are highly chances that you will ended up writing more and more codes. But there is a one way we can try to avoid it.

it simple mean is that you can create types from the existing types dynamically.

There are some helpful type annotation that let you to build types from types.

`keyof`

Let get start with keyof. keyof returns the union of keys of type OR interface. (consider keys as the left hand side properties of type and interface).

Let's take an example.

interface User {
   name: string;
   email: string;
   contactNumber: number;
}

// PropertyOfUser can be name | email | contactNumber
type PropetyOfUser = keyof User;

Generic Types

Generic types are fun. that basically let you pass a type as argument of another type that you can assign in various way.


// assigning default type, if nothing is provided. 
type User<GenderType = "male" | "female"> = {
   name: string;
   gender: GenderType;
}

type UserAccount = User<"male"> // pass that type as an argument.

This is a very made up example to explain you how the Generic Types work. You can assume this type similar like functions which take and argument and perform some tasks.

The given type is not recommended way to write User Type. It was just for the example.

This is really useful in various ways. Especially if you want to make more reusable types.

Type Indexing.

Type indexing gives type of particular property/key of interface or type.

Here's example.

type User = {
  name: string;
  gender: "male" | "female";
}

type genderOfUser = User["gender"]; // type indexing

This is very hypothetical example I have taken, but you can see that instead of writing male or female. We can just assign type index.

Mapping

Mapping is a process of iterating over keys of type and let you modify the type of that key.

Didn't get it? Let's see an example.


type User = {
  email: string;
  password: string;
}

type RequireUserFields = {
  [T in keyof User]: boolean; 
}

In above example we are just making another type by using User Type. We are iterating through the keys and assigning a boolean type. You can see the advantage here that you don't need to manually write all the keys of User type again.

This was very high level overview of How you can write dynamic types that avoid unnecessary typescript code.

If you found this helpful, please let me know your thoughts in comments.

If you think there is something wrong or missing. Please let me and other readers know about it.

If you want to ask some questions about typescript or anything about Front-end dev. You can reach me on Twitter.
@iponikar.

Thank you for reading this blog. See you soon with another one.

React Query

Ponikar — Fri, 07 Jan 2022 16:52:51 +0000

Hey there, I hope you are safe and well. Today I am going to write about React Query. What is a use of this library and Why you ever want to use it?

I've been working with this library for past 6 months and I was always asking myself like Why I didn't know about it before?

Why?

I firstly going to share Why you ever want to use something like react query? In React Ecosystem. We have everything from state management like Redux, MobX to UI libraries like material UI, etc.

But there is something that we always struggle especially me and that is API fetching. Yes that is true and I can bet you may have struggle with that too.

See, API fetching needs to do lots of things other than just fetching and rendering the list in front of user. If you really care about User Experience You may have followed this pattern like,

It's our responsibility to acknowledge user what is happening behind the scene. Like fetching data (Show loading indicator). If something went wrong show Error message and so on.

We always need to manually take care of all this stuff. Which I always struggle with that whenever I fetch APIs in components.

State Management. (Server States vs Local States)

I have been reading Kent C. Dodds's blog and He has specifically mentioned that there are two types of States (Data) we need to handle.

1) Server States
2) Local States

They need to handle individually other than just using Global state management libraries like Redux library.

One of the best example of this situation is Chat Messaging System.

In typically messaging app, You will see Loader whenever you send message and then the acknowledgment (Sent) and error (Message failed). In this situation you need to update states both sides.

This can become complex as you try to add more functionalities.

When I was learning React with Redux before, I thought redux will be the only one solution for all problems but then the day passed and I realised having a global state management is not sufficient to deal with all the challenges.

Caching

If you are beginner, You can ignore this but in simple words, Caching is a client side storage.
Whenever you request for data to server. Our browser cache (persists) data. Your browser will look into the cache before requesting data to server. This also allow us to manage caches by our own but there is no better way to implement that.

Caching perform a very crucial role in terms of scaling your app. You can learn more about caching on internet.

React Query

React query is solution for all the challenges that I have mentioned above. It is a data fetching library or I should introduced as Missing Piece of React Ecosystem. React Query take care of everything from managing local and server states, Caching states, Managing various API states like Loading, Error, Data, etc.

React Query wraps your app with Client Provider that manages caching and syncing of your states across all the components. (My favourite part). 😍

Enough talk, let's show the example.

We are going to fetch posts from Server with help of react query.

First we will wrap our App with `QueryClientProvider`.

   import { QueryClient, QueryClientProvider } from "react-query";
   const queryClient = new QueryClient();

   const App = () => { 
      return  <QueryClientProvider client={queryClient}>
       <Posts />
     </QueryClientProvider>
   }

We will use `useQuery` hook to fetch data.

This is just beginning.

import { useQuery } from "react-query";

const Posts = () => {
    const { isLoading, error, data } = useQuery('repoData', () =>
     fetch('https://jsonplaceholder.typicode.com/posts').then(res =>
       res.json()
     )
   )

   if (isLoading) return 'Please wait...'

   if (error) return 'Error' + error.message

   return (
     <div>
        <h1> Posts of the Day </h1>
        { data.map(post => <h1 key={post.id}> {post.title} </h1>) }
     </div>
});
}

useQuery hook that take care of fetching data from the server. Something like GET method. Notice how this hook abstract the loading and error handling part.

We didn't require to use try catch block here.

Key: key is unique for each request to identify each request uniquely.

Callback: This callback is callback that return async response. You can also use Axios here.

Note:

Once this hook fetch the data from server. It stores that data in cache memory. So when component try to make same request again instead of asking from server it will return that response from Cache Memory.

You can also invalidate your cache storage if you need fresh data from server. All you need to use useQueryClient hook from react-query.

We will see that example in next section. When we try to mutate data to server.

Before we can talk about data mutation. You may notice that you don't need to use Global state management libraries like redux to manage server states throughout components. Because We have already use Cache Memory. That will syncs your data automatically without dispatching any actions or updating any states manually. This will be really helpful for a complex React Application.

Data Mutation

Let's try send request of New Post to the server. We will use useMutation library to mutate data on server.

import { useMutation, useQueryClient } from "react-query";
const NewPost = () => {
   const client = useQueryClient();
   const { mutate, isLoading } = useMutation(async (newPost) => {
    return await Axios.post("https://myblog.app/new", {...newPost}, {
    // register all the callbacks,
    onMutate: () => {
       // this will be called when you invoke mutation method
      // ie like temporary showing blog
    },
    onError: (error) => {
     // this will be called when your API request get failed.
    },
    onSettled: () => {
    // this will work either way. (Success, Fail)
    },
    onSuccess: (response) => {
      // this will be called when your API request get 
     // executed successfully. 
     client.invalidateQueries("posts"); // will refetch posts
    }
});
})

 const newPost = () => {
    // add new post 
    mutate({ id: `temp-name`, title: "My Blog", content: "The content goes here..." }); 
 }


}

As you can you can easily mutate data on server. Also the callbacks help you to acknowledge user what is happening without setting up manually. You can compare that this is easy way to fetch APIs than what we were doing before.

The intention of writing this blog was let you know about this amazing library. Rather than manually handling the API Request sync with local states. which is can give you lots of headache.

I haven't covered everything of react-query library. You can prefer documentation for that.

If you have read the entire blog.
Thank you.

If you think there is something wrong in this blog. Feel free to correct me in comments. Share your thoughts in comments that are you going to use react-query or not.

If you want to discuss something with me. You can reach me out on twitter. My DM is always open. I would love to help you.

Twitter: @iponikar

Forem: Ponikar

What the heck is OpenClaw/Clawbot/MoltBot?

Why Are AI Agents Suddenly a Big Deal?

What Is an AI Agent?

Enter OpenClaw

An AI That Has Its Own World

Communication: How Do You Talk to It?

Dashboard

Agents

Memory System

Skills

Heartbeat (Cron Jobs)

So What’s the Real Breakthrough?

Final Thoughts

Building a performative React Native app

Profile

Rendering large list

Initial boot time

Illusion of lazy load

Synthetic sugar trade-offs

Imperative way to handle UI changes

Animations

Leveraging resources like GPU

C++ magic

Conclusion

Building React Native app that ship code from Mobile

Tech Stack

The workflow

GitHub OAuth flow

What about privacy?

@<filename> feature

Tool calling for rescue

Incremental changes support

The magical moment

Should You Work at a Startup?

The Odds of Success

The Plot

The Swiss Army Knife Engineer

The Turning Point

A Working Product Over Perfect Code

Hidden Levers

How Startups Create Wealth

Startups Are Ambiguous

A Continuous Learning Journey

AI as the Orchestrator

Rise of AI agents

Beyond prompt engineering

Tool calling on scale

Next gen wrapper

OTA updates in React Native

Disclaimer

What is OTA update?

Too Easy to break UX

Ground rules

What's my take on OTA updates?

We love building Cross Platform App!

TL;DR

The Plot

Picking the Tool that works for you

Nothing seems to be perfect

Seeking for Job opportunities

Building a Product

Don't be in dilemma

0 to 1, working in a startup as Software Engineer

Quick Note

TL;DR

The Plot

Turn of events

Validate Idea

SDE to Founding Engineer

Thinking about Product

Move Fast, Break Things

Work-life Balance

React Native is Multi Threaded

Disclaimer

Cue

Mobile Apps 📱

JavaScript is Single Threaded

Solution

Secret Sauce 🍝

`@<filename>` feature

Quick recap of `Types` and `Interface`

`keyof`

First we will wrap our App with `QueryClientProvider`.

We will use `useQuery` hook to fetch data.