DEV Community: Oyinlola Abolarin

5 Flutter Performance Mistakes I See in Most Codebases

Oyinlola Abolarin — Fri, 08 May 2026 01:37:41 +0000

Flutter gives you a lot out of the box. A fast rendering engine, a reactive UI model, and 60fps as the default expectation. But it is surprisingly easy to write Flutter code that quietly throws all of that away.

These five mistakes show up in real Flutter codebases constantly. None of them are obvious when you write them. All of them are fixable once you know what to look for.

1. Calling setState on a parent when only a child needs to rebuild

This is the Flutter equivalent of the giant React component problem, and it is probably the most common performance issue in Flutter apps. When you call setState on a parent widget, the entire subtree below it rebuilds. If that subtree contains complex layouts, images, or lists, you are doing a lot of unnecessary work on every state change.

The bad pattern:

class ParentWidget extends StatefulWidget {
  @override
  State<ParentWidget> createState() => _ParentWidgetState();
}

class _ParentWidgetState extends State<ParentWidget> {
  int counter = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        HeavyListWidget(), // rebuilds every time counter changes
        Text('$counter'),
        ElevatedButton(
          onPressed: () => setState(() => counter++),
          child: Text('Increment'),
        ),
      ],
    );
  }
}

The fix:

Extract the part that actually changes into its own StatefulWidget. HeavyListWidget never needs to rebuild when the counter changes, so it should not be in the same setState scope.

class CounterWidget extends StatefulWidget {
  @override
  State<CounterWidget> createState() => _CounterWidgetState();
}

class _CounterWidgetState extends State<CounterWidget> {
  int counter = 0;

  @override
  Widget build(BuildContext context) {
    return Column(
      children: [
        Text('$counter'),
        ElevatedButton(
          onPressed: () => setState(() => counter++),
          child: Text('Increment'),
        ),
      ],
    );
  }
}

Now HeavyListWidget lives outside this scope entirely and never rebuilds unless it needs to.

2. Building widgets inside the build method that should be constants

Flutter is declarative, which means build() gets called frequently. Anything you construct inside it gets reconstructed on every rebuild. If you are creating widgets that never change, declaring them as const tells Flutter to reuse the existing instance instead of building a new one.

The bad pattern:

@override
Widget build(BuildContext context) {
  return Column(
    children: [
      Padding(
        padding: EdgeInsets.all(16),
        child: Text(
          'Welcome',
          style: TextStyle(fontSize: 24, fontWeight: FontWeight.bold),
        ),
      ),
    ],
  );
}

The fix:

@override
Widget build(BuildContext context) {
  return const Column(
    children: [
      Padding(
        padding: EdgeInsets.all(16),
        child: Text(
          'Welcome',
          style: TextStyle(fontSize: 24, fontWeight: FontWeight.bold),
        ),
      ),
    ],
  );
}

The const keyword here is not just a style preference. Flutter skips the widget entirely during reconciliation if it is const and nothing about it has changed. Enable the prefer_const_constructors lint rule in your analysis_options.yaml and let the analyzer flag every missed opportunity automatically.

3. Using ListView instead of ListView.builder for long lists

When you use ListView with a children list, Flutter builds every single item upfront regardless of whether it is visible on screen. For short static lists this is fine. For anything that scrolls, it is a serious problem.

The bad pattern:

ListView(
  children: items.map((item) => ItemCard(item: item)).toList(),
)

If items has 500 entries, Flutter builds 500 ItemCard widgets before the user even sees the list.

The fix:

ListView.builder(
  itemCount: items.length,
  itemBuilder: (context, index) {
    return ItemCard(item: items[index]);
  },
)

ListView.builder is lazy. It only builds widgets that are currently visible plus a small buffer. The performance difference on long lists is significant and very easy to measure in DevTools.

For lists where items have varying heights, use ListView.builder with a cacheExtent value tuned to your typical item height to control how aggressively Flutter pre-builds off-screen items.

4. Performing heavy work directly inside build()

The build method runs on the UI thread and should be as fast as possible. Sorting a list, filtering data, parsing a string, running a computation, none of that belongs inside build(). Every rebuild triggers it again, and if it is slow, your frame rate pays for it.

The bad pattern:

@override
Widget build(BuildContext context) {
  final sorted = items.where((i) => i.isActive).toList()
    ..sort((a, b) => b.createdAt.compareTo(a.createdAt));

  return ListView.builder(
    itemCount: sorted.length,
    itemBuilder: (context, index) => ItemCard(item: sorted[index]),
  );
}

Every rebuild refilters and resorts the entire list.

The fix:

late List<Item> _sortedItems;

@override
void initState() {
  super.initState();
  _sortedItems = _computeSortedItems();
}

List<Item> _computeSortedItems() {
  return items.where((i) => i.isActive).toList()
    ..sort((a, b) => b.createdAt.compareTo(a.createdAt));
}

Compute once in initState and only recompute when the source data actually changes. If the computation is expensive enough, push it to an isolate so it runs off the UI thread entirely.

5. Not using RepaintBoundary to isolate expensive widgets

Flutter repaints widgets in layers. By default, an animation or a frequent update in one part of the screen can trigger repaints in completely unrelated widgets nearby. RepaintBoundary tells Flutter to isolate a widget into its own layer so its repaints stay contained.

The bad pattern:

Stack(
  children: [
    BackgroundMapWidget(),   // expensive, static
    AnimatedMarkerWidget(),  // updates 60 times per second
  ],
)

Every frame of the animation repaints the entire Stack including the background map.

The fix:

Stack(
  children: [
    RepaintBoundary(
      child: BackgroundMapWidget(),
    ),
    AnimatedMarkerWidget(),
  ],
)

Now the map has its own layer. The animation repaints only the marker layer and the map is untouched. This is especially valuable for anything with continuous animations running alongside complex static UI maps, charts, video players, and similar heavy widgets.

You can verify it is working by opening the Flutter DevTools, enabling "Highlight repaints", and watching which parts of the screen flash on each frame. If the map stops flashing, RepaintBoundary is doing its job.

Wrapping up

Flutter is fast by design, but the framework cannot protect you from all of these patterns on its own. setState scope, const widgets, lazy lists, build method purity, and repaint isolation are four habits that separate apps that feel smooth from apps that feel like they are fighting the framework.

The Flutter DevTools Performance tab and the Widget Rebuild tracker are your best tools for catching these in practice. Run a profile build, not a debug build, when profiling the numbers will be completely different.

If this was useful, I write about Flutter, React, and frontend engineering regularly. Follow along for more.

5 React Performance Mistakes That Are Slowing Your App Down

Oyinlola Abolarin — Mon, 04 May 2026 00:42:14 +0000

Most React performance problems are not architectural. They are not about picking the wrong state manager or choosing the wrong rendering strategy. They are small habit things that look perfectly fine in isolation but compound quietly across a codebase until your app feels sluggish and you are not sure why.

This article covers five of the most common ones, with code examples so you can see exactly what to change.

1. Inline objects and functions in JSX

This one is everywhere. You write a style or a handler directly inside JSX and it looks clean. The problem is that JavaScript creates a new object or function reference on every render. React does a shallow comparison when deciding whether to re-render a child, and since the reference is always new, the child always re-renders, even when nothing meaningful has changed.

The bad pattern:

<Card style={{ padding: 16, borderRadius: 8 }} onClick={() => handleClick(id)} />

The fix:

const cardStyle = { padding: 16, borderRadius: 8 }

function Parent() {
  const handleClick = useCallback((id) => {
    // handle it
  }, [])

  return <Card style={cardStyle} onClick={handleClick} />
}

Move static objects outside the component entirely. For functions that depend on state or props, useCallback is appropriate, but only when the child that receives it is memoized. Otherwise you are optimizing nothing.

2. Overusing useMemo and useCallback

This one tends to get worse as developers get more experienced, because it feels like you are being careful. The reality is that memoization has its own cost. React has to store the previous value, compare dependencies, and decide whether to recompute. For cheap computations, that overhead often costs more than just running the calculation again.

Unnecessary memoization:

const fullName = useMemo(() => {
  return `${firstName} ${lastName}`
}, [firstName, lastName])

That is a string concatenation. It does not need useMemo.

When it actually makes sense:

const sortedList = useMemo(() => {
  return items.sort((a, b) => b.score - a.score)
}, [items])

Sorting a large array on every render is the kind of work worth memoizing. The rule is simple: profile first, then memoize only what measurement shows is actually slow.

3. One giant component doing everything

You know this component. It fetches data, manages three different pieces of state, handles user interactions, and renders a full page of UI all in one place. Every state update, no matter how small, triggers a re-render of the entire thing.

The fix is not complicated. Split your components into two types:

Container components handle the logic. They manage state, make API calls, and pass data down as props. They do not render complex UI.

Presentational components are pure display. They receive props and render. Because they have no local state, they only re-render when their props actually change, and wrapping them in React.memo becomes straightforward and effective.

// Container
function UserProfileContainer() {
  const { data, isLoading } = useUserProfile()
  if (isLoading) return <Spinner />
  return <UserProfileCard user={data} />
}

// Presentational
const UserProfileCard = React.memo(function UserProfileCard({ user }) {
  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  )
})

This pattern also makes testing much easier as a side benefit.

4. Storing derived state in useState

If a value can be computed from props or from state you already have, it does not need its own useState. Storing it separately means you have two sources of truth for the same piece of data, and keeping them in sync requires extra code that is easy to get wrong.

The bad pattern:

const [firstName, setFirstName] = useState('')
const [lastName, setLastName] = useState('')
const [fullName, setFullName] = useState('')

useEffect(() => {
  setFullName(`${firstName} ${lastName}`)
}, [firstName, lastName])

This causes a double render every time firstName or lastName changes, because the state update inside useEffect triggers another render cycle.

The fix:

const [firstName, setFirstName] = useState('')
const [lastName, setLastName] = useState('')

const fullName = `${firstName} ${lastName}`

Compute it during render. It is simpler, it is always in sync, and it renders once instead of twice.

5. Using array index as a list key

React uses keys to track which items in a list have changed between renders. When you use the array index as the key, React cannot tell the difference between an item that moved and an item that changed. This leads to wrong state being mapped to the wrong component, animation bugs, and slower reconciliation.

The bad pattern:

items.map((item, index) => (
  <TodoItem key={index} item={item} />
))

Reorder the list, remove an item from the middle, or insert at the top, and React will get confused about which component is which.

The fix:

items.map((item) => (
  <TodoItem key={item.id} item={item} />
))

Always use a stable, unique identifier. If your data does not have IDs, generate them when the data is created, not at render time.

Wrapping up

None of these are obscure edge cases. They show up in production codebases every day, including ones written by experienced engineers. The reason they persist is that they rarely cause obvious crashes, they just quietly make things slower.

The best way to catch them is a combination of code review habits and the React DevTools Profiler. Record a session, look at what is re-rendering more than it should, and work backwards from there.

If this was useful, I write about React, Flutter, and frontend engineering regularly. Follow along for more.

I Got Tired of Copy-Pasting IBAN Validation Code Across Every Project — So I Built Two Open Source Packages

Oyinlola Abolarin — Wed, 15 Apr 2026 15:02:07 +0000

Announcing iban_validator for Flutter/Dart and iban-validate for TypeScript/JavaScript

There is a piece of code I have written at least four times in the last two years.

It strips spaces from a string, converts letters to numbers, rearranges some characters, and computes a modular arithmetic checksum. It validates IBAN numbers, the international bank account format used for cross-border payments, and it lives in a different file in a different language in every project I have ever worked on that needed it.

Flutter app? I write it in Dart. React dashboard? I write it in TypeScript. New project six months later? I find the old file, copy it across, tweak it slightly, and inevitably introduce a subtle bug that only shows up when a user from Norway tries to make a payment because Norwegian IBANs are 15 characters and I hardcoded 16 somewhere.

I got tired of it. So I built it properly.

Today, I am releasing two open source packages:

iban_validator for Dart and Flutter — pub.dev/packages/iban_validator
iban-validate for TypeScript and JavaScript — npmjs.com/package/iban-validate

Both support 116 countries, implement the official ISO 7064 MOD-97–10 validation algorithm, return typed errors with human-readable messages, and have zero production dependencies.

This article explains why I built them, how the algorithm works, what makes them different from existing solutions, and how to use them in your project.

What is an IBAN and why does validation matter?

IBAN stands for International Bank Account Number. If you have sent money internationally, especially within Europe, or to the Middle East, you have used one. They look like this:

DE89 3704 0044 0532 0130 00   ← Germany
GB29 NWBK 6016 1331 9268 19   ← United Kingdom
SA44 2000 0001 2345 6789 1234  ← Saudi Arabia
CI93 CI00 8011 1301 1342 9120 0589  ← Ivory Coast

The first two characters are the ISO country code. The next two are check digits. The rest is the domestic bank account number in a country-specific format. Every country that uses IBAN has a fixed, registered length. Germany is always 22 characters, Norway is always 15, and Malta is always 31.

What makes IBAN genuinely interesting from an engineering perspective is that the check digits are mathematically derived from the rest of the number. This means you can detect errors, transposed digits, missing characters, typos, before you ever attempt to send the payment.

In fintech, that matters. A failed international transfer is not just an inconvenience. It can mean frozen funds, customer support tickets, refund delays, and, in some cases, fees charged by intermediate banks for routing a payment that bounced. Catching a bad IBAN at the moment a user types it, rather than after submission, is genuinely valuable.

How the validation algorithm works

The algorithm is defined in ISO 7064 and has five steps. I want to walk through it properly because understanding it will make the code make sense.

Step 1 — Clean the input

Strip all spaces and convert to uppercase. Users type IBANs in all sorts of formats with spaces, without spaces, in lowercase. The algorithm does not care about any of that. Normalise first.

"de89 3704 0044 0532 0130 00"  →  "DE89370400440532013000"

Step 2 — Validate the country and length

The first two characters identify the country. Every IBAN-supporting country has a fixed, registered length defined by the SWIFT IBAN Registry. Germany’s IBANs are always 22 characters. If you receive a 21-character string starting with DE, it is wrong before you even look at the checksum.

This step alone catches a large proportion of errors.

Step 3 — Rearrange the string

Move the first four characters of the country code plus the two check digits to the end of the string.

"DE89370400440532013000"  →  "370400440532013000DE89"

Step 4 — Convert letters to numbers

Replace every letter with its numeric equivalent: A=10, B=11, C=12, and so on up to Z=35. This converts the alphanumeric string into a pure digit string.

"370400440532013000DE89"
→ "370400440532013000" + "13" + "14" + "89"
→ "3704004405320130001314 89"

D becomes 13, E becomes 14, because D is the 4th letter (A=10, B=11, C=12, D=13).

Step 5 — Compute mod 97

Interpret the entire digit string as a large integer and compute its remainder when divided by 97. If the remainder equals exactly 1, the IBAN is valid.

3704004405320130001314 89  mod  97  =  1  ✓

The mathematical reason this works is rooted in number theory; the check digits were specifically chosen during IBAN generation to make this remainder equal 1. Any single-character error or transposition will (in virtually all cases) produce a different remainder.

The integer overflow problem

Here is the engineering challenge: that digit string can be up to 34 characters long, representing a number around 1⁰³⁴. JavaScript’s Number type can only safely represent integers up to about 9×10¹⁵. Dart int handles arbitrary sizes natively on VM platforms, but for portability across web and mobile, you want to avoid relying on that.

The solution is to process the digit string in 7-character chunks, carrying the remainder forward at each step. The result after all chunks is mathematically identical to computing mod 97 on the entire number in one go, and every intermediate value stays well within safe integer range on every platform.

No BigInt. No external dependencies. Just arithmetic.

What was missing from existing solutions

Before building these packages, I looked at what existed. The picture was not great.

European-only coverage. Most IBAN libraries were built by European developers for European use cases. They covered SEPA countries well and quietly ignored the rest of the world. If you needed to validate a Bahraini IBAN (BH, 22 characters) or a Kazakh IBAN (KZ, 20 characters), You were on your own.

Boolean returns. The majority of libraries returned true or false. That is fine for a basic check, but useless for building good user experiences. When validation fails, your UI needs to know why to show the right error message, to highlight the right field, and to give the user actionable guidance.

No metadata. Length constraints, SEPA membership, and sample IBANs were not available. You could not build a country picker that showed only supported countries, or a length hint that updated as the user selected their country.

Abandonment. Several of the most-starred packages had not been updated in two or three years. The IBAN registry is not static; new countries are added, and formats occasionally change.

What I built instead

116 countries

The official SWIFT IBAN Registry has 94 registered countries as of March 2026. I added 22 more, mostly in Africa, that have adopted IBAN-like formats locally but are not yet formally registered. These include the Ivory Coast, Senegal, Mali, Cameroon, Togo, Burkina Faso, Benin, Niger, and others. They are flagged as isExperimental: true in the registry so you can make an informed decision about whether to trust them in production.

The African coverage matters to me personally. A significant amount of fintech development is happening across West and East Africa right now, and developer tooling often lags behind. If you are building a payment product for this market, you need these country codes.

Typed errors

Both packages return a result object with a typed error and a human-readable message.

// Flutter / Dart
final result = IbanValidator.validate('DE99370400440532013000');

if (!result.isValid) {
  print(result.error);
  // IbanValidationError.checksumFailed

  print(result.errorMessage);
  // "The mod-97 checksum failed. The IBAN contains an error."

  print(result.countryInfo?.countryName);
  // "Germany"
}

// TypeScript / JavaScript
const result = validate('DE99370400440532013000');

if (!result.isValid) {
  console.log(result.error);
  // 'checksumFailed'

  console.log(result.errorMessage);
  // 'The mod-97 checksum failed. The IBAN contains an error.'

  console.log(result.countryInfo?.countryName);
  // 'Germany'
}

The possible error values are:

Error	Meaning
`emptyInput`	Input was empty
`tooShort`	Fewer than 4 characters
`invalidCharacters`	Contains characters outside A–Z and 0–9
`unknownCountry`	Country code not in the registry
`countryMismatch`	Doesn't match the country constraint you passed
`invalidLength`	Wrong length for the country
`checksumFailed`	The mod-97 check failed, likely a typo

This means you can show specific, actionable error messages rather than a generic "invalid IBAN" that leaves the user guessing.

Country metadata

Both packages expose a full country registry you can query at runtime.

// Dart
final info = IbanValidator.getCountryInfo('CI')!;
info.countryName;    // 'Ivory Coast'
info.ibanLength;     // 28
info.isSepa;         // false
info.isExperimental; // true
info.example;        // 'CI93CI0080111301134291200589'

// Useful for building country pickers, length hints, etc.
final sepaCountries = IbanValidator.getSepaCountries();
final africanCountries = IbanValidator.getExperimentalCountries();

// TypeScript
const info = getCountryInfo('SA')!;
info.countryName; // 'Saudi Arabia'
info.ibanLength;  // 24
info.isSepa;      // false
info.example;     // 'SA4420000001234567891234'

Consistent API across both ecosystems

This was the design constraint I cared about most. If you use both packages, Flutter for mobile, React for web, the mental model should be identical.

Flutter/Dart	TypeScript/JS
`IbanValidator.isValid(iban)`	`isValid(iban)`
`IbanValidator.validate(iban)`	`validate(iban)`
`IbanValidator.getCountryInfo('DE')`	`getCountryInfo('DE')`
`IbanValidator.getSepaCountries()`	`getSepaCountries()`

Same country registry. Same validation logic. Same error vocabulary. Your mobile and web products behave identically, and switching between codebases does not require context-switching in your head.

Using the packages in practice

Flutter

Add to pubspec.yaml:

dependencies:
  iban_validator: ^1.0.0

Basic form validation:

import 'package:iban_validator/iban_validator.dart';

TextFormField(
  decoration: const InputDecoration(labelText: 'IBAN'),
  validator: (value) {
    if (value == null || value.trim().isEmpty) {
      return 'Please enter your IBAN.';
    }
    final result = IbanValidator.validate(value);
    return result.isValid ? null : result.errorMessage;
  },
)

Country-constrained validation (when your app already knows the user's country):

final result = IbanValidator.validate(
  ibanInput,
  countryCca2: selectedCountryCode, // e.g. 'FR', 'AE', 'CI'
);

TypeScript / JavaScript

Install:

npm install iban-validate
# or
yarn add iban-validate

With React Hook Form:

import { isValid } from 'iban-validate';

<input
  {...register('iban', {
    validate: (value) => isValid(value) || 'Please enter a valid IBAN.',
  })}
/>

With Zod:

import { z } from 'zod';
import { isValid } from 'iban-validate';

const schema = z.object({
  iban: z.string().refine(isValid, {
    message: 'Please enter a valid IBAN.',
  }),
});

In a Next.js API route:

import { validate } from 'iban-validate';

export async function POST(req: Request) {
  const { iban } = await req.json();
  const result = validate(iban);

  if (!result.isValid) {
    return Response.json(
      { error: result.error, message: result.errorMessage },
      { status: 422 }
    );
  }

  // Safe to use result.cleanedIban from here
  await processPayment(result.cleanedIban);
}

CommonJS also works:

const { isValid } = require('iban-validate');
console.log(isValid('DE89 3704 0044 0532 0130 00')); // true

What is next

A few things I want to add in upcoming versions:

Format helpers. A formatIban function that takes a raw IBAN string and returns it in the standard human-readable grouped format (DE89 3704 0044 0532 0130 00). Useful for display.

More African countries. The continent is rapidly adopting IBAN and I want to stay ahead of that. Several countries are in the process of formal SWIFT registration.

BBAN extraction. Pull out the domestic bank code and account number from the IBAN for countries where the format is well-defined. This would let you display the sort code from a UK IBAN or the Bankleitzahl from a German one.

If there is something you need that is not there, open an issue on GitHub. PRs are very welcome.

Find the packages

Flutter / Dart
pub.dev → pub.dev/packages/iban_validator
GitHub → github.com/khrisbreezy/iban_validator

TypeScript / JavaScript
npm → npmjs.com/package/iban-validate
GitHub → github.com/khrisbreezy/iban-validation

Both are MIT licensed. If you use them, the best thing you can do is star the GitHub repos and leave a like on pub.dev. It helps other developers find them.

And if you are building something in fintech, especially for African or Middle Eastern markets, I would genuinely love to hear what you are working on.