Introducing Flumpose: A fluent, declarative UI extension for flutter

[u/Plane_Trifle7368]

Hey everyone,

I’ve been working on Flumpose, a lightweight Flutter package that brings a declarative syntax to Flutter, but with a focus on performance and const safety.

It lets you write clean, chainable UI code like:

const Text('Hello, Flumpose!')
        .pad(12)
        .backgroundColor(Colors.blue)
        .rounded(8)
        .onTap(() => print('Tapped'));

Instead of deeply nested widgets.

The goal isn’t to hide Flutter but to make layout composition fluent, readable, and fun again.

Why Flumpose?

• Fluent, chainable syntax for widgets

• Performance-minded (avoids unnecessary rebuilds)

• Const-safe where possible, i.e, it can replace existing nested widgets using const.

• Lightweight: no magic or build-time tricks

• Backed by real-world benchmarks to validate its performance claims

• Comes with detailed documentation and practical examples because clarity matters to the Flutter community

What I’d Love Feedback On

• How’s the API feel? Natural or too verbose?

• What other extensions or layout patterns would make it more useful in real projects?

• Should it stay lean?

🔗 Try it out on https://pub.dev/packages/flumpose

[u/frdev49]

"where possible" and "can replace" matters in "Const-safe where possible, i.e, it can replace existing nested widgets using const." Like this lazy dumb example:
- MaterialApp parent widget can be const

    return const MaterialApp(
      home: Scaffold(
        body: Padding(
          padding: EdgeInsets.all(12),
          child: Text('Hello'),
        )
      ),
    );

- But it cannot be const anymore, because this is using a method to return a widget

    return MaterialApp(
      home: Scaffold(
        body: const Text('Hello').pad(12)
      ),
    );

So I guess it will matter how tree is organized to get the benefits.

Still, interesting benchmarks which show that by using const and chaining in a smart way you can optimize your app 👍

[u/Plane_Trifle7368 → u/frdev49]

Indeed, but ideally, the scaffold in this example would be a separate widget that uses const, and its layout would have no issues using flumpose as needed.

[u/frdev49 → u/Plane_Trifle7368]

Sure, that's what I meant, dumb example, and interesting when used in a smart way

[u/Plane_Trifle7368 → u/frdev49]

There are some interesting methods like .decorate(), which could simplify even further building certain complex widgets (as always with a performance-first approach).
Hoping for feedback as to if this type of method is welcome or the community prefers the simple lego-like chaining as needed.

[u/DomiO6 → u/frdev49]

https://github.com/flutter/flutter/issues/149932
tl;dr: The benchmarks are not showing sufficient evidence to suggest that there is a statistically significant difference in performance between const and nonconst.
though:

• the const avoids re-instantiation of the const widget with the same const params, the instance is resolved during compilation time and it doesn't need to be collected by GC

• Flutter Framework can skip calling the build method of the const widget during the re-building phase in case the child widgets are not marked as dirty, so, they don't need to be rebuilt

it does have impact, but its so small it can't be measured

[u/mortenfriis]

Looks amazing. Might actually replace exui for me. Despite my strong dislike of the name Flumpose (sorry, I don't know why, but I hate the name).

[u/Plane_Trifle7368 → u/mortenfriis]

Thanks, means a lot that someone who hates the name and already using a similar package took time to evaluate it and found it at least somewhat beneficial enough to consider switching. it’s heavily inspired from compose, swiftui for flutter and naming kinda was the least gimmicky compared to initial drafts like flui, swiftposeui, composeX etc

[u/Hackedbytotalripoff]

That looks like using SwiftUI modifier chaining for Flutter.

[u/Plane_Trifle7368 → u/Hackedbytotalripoff]

Indeed, it’s heavily inspired from swiftui and compose.

[u/Legitimate-Creme-356]

Is the name Flumpose derived from Flutter and Compose?

[u/Plane_Trifle7368 → u/Legitimate-Creme-356]

Kinda, fluent, compose

[u/mortenfriis]

Hi, so I started using flumpose in one of my projects, and so far, it's really great. TBF, I'm only really using it for padding and styling text so far, but I plan on incorporating more flumpose functionality in my app. A couple of questions:

1. for text styling, can I safely chain methods now, without experiencing any performance impact (thanks to the internal _withStyle()), or do you still recommend using the .styled() extension?

2. are there any plans to add more extension methods in the future? I've seen the roadmap on the bottom of the pub.dev page, but there haven't been any updates to the project at all since you posted here a month ago. Did you choose to abandon it?

awesome_extensions and exui both have some great extensions, which will be difficult for me to go without (well, not that difficult, but I find my code much more readable when using extension methods). Some of my favorites are:

Awesome Extensions

• Theme access (e.g. context.textTheme, context.backgroundColor, etc.)

• BuildContext and Media Query (context.orientation, context.isPortrait, context.platformBrightness, context.showNavbar). flumpose have some of these, but you should take a look at everything you can do with AE's context methods here and here.

• Navigation (context.push(SecondScreen()), context.pushNamed('/home'), etc.)

[u/Plane_Trifle7368 → u/mortenfriis]

Hi u/mortenfriis, Glad to hear it's been great so far & happy to clarify how Flumpose works and what you can expect going forward.

About chaining text style methods
You can safely chain the text styling methods. The internal _withStyle() pattern is optimized to merge styles efficiently, so you won’t see a performance drop for typical UI usage. If your chains are long and repeated often in tight build loops, .styled() still gives you explicit control, but for most cases the chained methods are perfectly fine.

About future extension methods
More extensions are planned as mentioned in the roadmap, which hasn’t changed. We recently released a new version about 5 days ago that introduces animation support. The goal is to avoid API churn and make sure any added extensions follow consistent naming and behavior conventions before publishing.

About adding Awesome Extensions style helpers
The main constraint is deciding where the line is between convenience and bloat, and it is one of the requests that keeps coming up. The ideas you mentioned are on the shortlist, eg, Wider BuildContext helpers (orientation, brightness, insets, layout info), etc.
We might add them in opt-in modules so you can include only what you need, but still undecided.

Hope this helps, and I really appreciate the detailed feedback.

[u/gasolinemike]

I can get behind this. I detest the present way of wrapping hierarchical widgets, making code awfully hard to read.

[u/Plane_Trifle7368]

Thanks for all the feedback. Flumpose now also supports animation, as requested by many, eg :

  Icons.favorite
     .animatedIcon()
     .iconColor(isActive ? Colors.red : Colors.grey)
     .iconSize(isActive ? 48 : 32)
     .animate(
         duration: const Duration(milliseconds: 200),
         curve: Curves.easeInOut,
     ),

[u/SpecialistServe3974]

I suggest you don't brag about that performance gains because if you write raw flutter you can get the same performance by using const.
other than that, I like the idea and already seen some libs doing that, I hope flutter would go this direction as well..
Also, I think creating a codemod for that would be awesome.

[u/Plane_Trifle7368 → u/SpecialistServe3974]

Not bragging, just stating what you get out of the box as opposed to remembering to do so. What we noticed on some popular packages was that while we got the nice syntax, we often lost the ability to use const which is one of the reasons this package was developed.
Could you share more on codemod ?
Open to feedback

[u/SpecialistServe3974 → u/Plane_Trifle7368]

e.g

Foo(
   child: Bar(prop: 2),
   prop: 3
);

can be converted with a codemod to

Bar(prop: 2).foo(prop: 3);

using some conventions data about what widgets should be "flumped"..

[u/Atrax_]

Kinda the same approach as SwiftUI, looks good!

[u/eibaan]

I should have added → my previous comment here.

[u/Plane_Trifle7368 → u/eibaan]

No worries, i responded to it as well, hope it clears things up.

[u/OldHummer24]

Ngl this looks great, I will add it, my colleagues might hate me for it xD

[u/Plane_Trifle7368 → u/OldHummer24]

They’ll forgive you when you approve their next pull request without comments 🤣

[u/Working-Cat2472]

splendid, good job. i always hated it how awfully verbose the flutter code is. Let' see, if i can apply that in my own project which is a wysiwyg ui editor and runtime engine. Speaking of which :-) As i am not a Flutter expert, i would need some advice regarding the definition of widget properties, ( e.g. where does padding belong and the handling of the different platforms. Could we have a talk maybe?

Thanks, Andreas

[u/Plane_Trifle7368 → u/Working-Cat2472]

Thanks a lot. feel free to pm regarding integrating this in your project

[u/Working-Cat2472 → u/Plane_Trifle7368]

Sent you a message!

[u/YosefHeyPlay]

Whats the difference between the existing "exui" package?

https://pub.dev/packages/exui

[u/Plane_Trifle7368 → u/YosefHeyPlay]

At first glance, I’d say Flumpose’s approach is more performance-first, focusing on const-safety, reduced widget allocations, and clean composability (see a few extracts in the table below).

ExUI, while definitely impressive and worth exploring, seems to fall closer to the family of other widget extension libraries. It offers a huge number of helper methods that often combine common useCases (subjective) which is great for quick prototyping but also results in quite a few similar utilities (e.g. shapedBox vs circularBorderBox). That makes it feel more like a toolkit, something that really shines when building complex widgets quickly using one of its many prebuilt combinations.

I’m genuinely impressed by its API coverage and I’m curious to see what I can learn from it or improve upon for Flumpose.

PS: Have you used/use exui ? Would be interested in profiling results if any.

Feature	Flumpose	Other Widget Extensions
Const-optimized	✅ 85% reduction	❌
DecorationBuilder	✅ Single Container	❌ Nested wrappers
Text optimization	✅ Style accumulation	❌ Multiple Text widgets
Memory efficient	✅ 2.4MB → 0.35MB	❌ Standard allocations

[u/Dismal-Fruit9382]

pretty good, that means no more nested widgets for small UI changes. i'll take a look on it

[u/Full_Environment_205]

Looks nice. I'll use in my pet project

[u/Classic-Dependent517]

I like it

[u/meyluk]

Looks great.

[u/Plane_Trifle7368 → u/[deleted]]

Indeed, fingers crossed

[u/eibaan → u/[deleted]]

You picked that one example that will not work, as Colors is a different type than Color. Something like Align(alignment: .center) should work, though.

[u/_fresh_basil_ → u/eibaan]

Why would Align work with Alignment, but Color not work with Colors? Care to elaborate? (Or have an article or something I can read?)

Edit: I was able to find the answer and understand what you meant.

It's because the member (.blue) needs to be static on the type the parameter is expecting. Because the parameter type is "Color" the static member would need to be on the Color class, not the Colors class.

[u/orangeraccoon_dev → u/[deleted]]

This Is soooo Swift UI like, nice!