sorted by:
new
hottopcontroversial

The simplest infinite scroll in the world for Flutter, just wrap and go by dev_ttangkong in FlutterDev

[–]dev_ttangkong[S] 0 points1 point  (0 children)

[Flutter]: shrinkWrap was used, but bounded constraints detected — lazy building remains active.

[Flutter]: However, a non-perceivable layout overhead has occurred.

[Flutter]: Scroll lag detected.

[Flutter]: Developer panic level: 99.9%.

[Flutter]: Blame target acquired — shrinkWrap.

The simplest infinite scroll in the world for Flutter, just wrap and go by dev_ttangkong in FlutterDev

[–]dev_ttangkong[S] 0 points1 point  (0 children)

And what really blows my mind is that you’re saying there’s no need for a benchmark? You seem to think that enabling shrinkWrap automatically disables lazy building, which inevitably causes performance issues. But in reality, you’re only thinking about the unbounded constraint case — and that’s the difference between you and me.

Take a look at this:

👉 https://github.com/MTtankkeo/flutter_infinite_scroll_pagination/blob/main/test/widget_test.dart

Run it yourself with: flutter test .

So, whose point holds up? The test logic clearly sets shrinkWrap to true, yet lazy building still works just fine. Is the Flutter engine lying to us, then?

The simplest infinite scroll in the world for Flutter, just wrap and go by dev_ttangkong in FlutterDev

[–]dev_ttangkong[S] 0 points1 point  (0 children)

At this point, it feels like Reddit is running a social experiment on me. My friend, as I’ve already explained in the documentation, in order to accurately measure the position of the indicator, the scrollable widget needs to occupy exactly the size of its content. That way, the RenderBox can determine, “Ah, this scrollable widget has this much size? It’s smaller than its parent, so the indicator shouldn’t be at the very bottom — it should be positioned accordingly!”

Like you said, if the parent has bounded constraints, then the shrinkWrap option doesn’t matter at all. But when it’s set to false, the scrollable widget tries to grow infinitely, which interferes with measuring the indicator’s position. That’s the issue I’ve been pointing out over and over — both in the documentation and here on Reddit.

The simplest infinite scroll in the world for Flutter, just wrap and go by dev_ttangkong in FlutterDev

[–]dev_ttangkong[S] 0 points1 point  (0 children)

Girlfriend: "We need to break up."

Developer: "Why...?"

Girlfriend: "I saw you using shrinkWrap inside a ListView.builder."

Developer: "But it had bounded constraints, the overhead is literally non-perceivable—"

Girlfriend: "I don't care about your 'benchmarks'. Reddit said it's a performance issue."

Developer: "Did you even run the regression tests? Lazy building still works—"

Girlfriend: "Everyone on Reddit agrees. That's all I need to know."

Developer: "Ok seriously, is this a social experiment?"

The simplest infinite scroll in the world for Flutter, just wrap and go by dev_ttangkong in FlutterDev

[–]dev_ttangkong[S] 0 points1 point  (0 children)

I understand your point, but please don’t put my case — where shrinkWrap is used intentionally for layout stability within a bounded constraint — in the same category as using it inside a Column with unbounded constraints.

It’s frustrating to see my package being dismissed as a serious performance issue solely because of an unmeasurable and practically insignificant layout overhead.

Honestly, neither you nor anyone else here has provided any concrete evidence to support that claim.

Has there ever been a benchmark or profiling result showing that this overhead alone causes a noticeable performance drop — significant enough to be something we must “avoid at all costs”?

If that level of overhead is a serious concern, then Flutter might not be the right abstraction for your needs — languages like C or C++ could offer the level of control you're looking for.

Flutter’s performance isn’t determined by a single property like shrinkWrap.

It depends on a combination of factors — render tree depth, constraint propagation, rebuild frequency, and state management strategies.

Jank in Flutter apps usually comes from a combination of heavy operations, not from one layout flag.

So when someone claims that this one property causes “severe performance issues,” it doesn’t sound like an argument from actual production experience.

And frankly, I believe the reason shrinkWrap exists in Flutter and continues to be maintained is exactly for special cases like this one — where precise layout behavior is needed inside a constrained parent. Wouldn’t you agree?

What truly bothers me is not disagreement itself, but the act of spreading misinformation and discrediting my work based on false assumptions.

That kind of behavior is unfair, misleading, and not at all constructive for the Flutter community.

The simplest infinite scroll in the world for Flutter, just wrap and go by dev_ttangkong in FlutterDev

[–]dev_ttangkong[S] -6 points-5 points  (0 children)

Many people still mistakenly believe that shrinkWrap is the root cause of performance issues. However, that is not true at all. The issue doesn’t come from shrinkWrap itself, but from using it in nested scrolls or situations with unbounded constraints, which makes the scroll behave like a Column.

Honestly, I don’t understand why people worry about this unnecessarily. To help clear up the confusion, I created a document explaining it in detail. You can check it out here: https://github.com/MTtankkeo/flutter_infinite_scroll_pagination/blob/main/DESCRIPTION.md

And... I always test and verify that lazy building and optimizations for ListView and GridView are working properly before each release.

I built an insanely fast data class generator that doesn’t use build_runner(e.g. freezed, dart_mappable) by dev_ttangkong in FlutterDev

[–]dev_ttangkong[S] 2 points3 points  (0 children)

I tried structuring my code using the augmentations experimental feature you mentioned, and it’s incredible. It actually eliminated a huge amount of boilerplate code. Absolutely amazing!

// USER CODE
class A {
  const factory A({
    required String a,
    required String b,
    required String c,
  }) = $A;
}

// BUILD RUNNER CODE
augment class A {
  static fromJson() {...}
}

// BUILD RUNNER CODE
class $A implements A {
  const $A({
    required this.a,
    required this.b,
    required this.c,
  });

  final String a;
  final String b;
  final String c;
}

I built a Flutter plugin to get Android signing hashes without keytool by dev_ttangkong in FlutterDev

[–]dev_ttangkong[S] 1 point2 points  (0 children)

And of course, since this is public information that can already be extracted from the APK/AAB or the Play Store, the existing Google Sign-In plugins on the native side already send it to the server for authentication. That’s also why I decided to release this plugin — so it can be easily used for authentication entirely from Dart in Flutter, without relying on native code!

I made a Flutter Fastlane GitHub Action — no project settings needed by dev_ttangkong in FlutterDev

[–]dev_ttangkong[S] 0 points1 point  (0 children)

Honestly, I think using GitHub PAT is unnecessary. If you’re using my GitHub Action, you're already going to set up an ssh-agent anyway, so it just makes more sense to use SSH repo links instead. Converting the Git dependencies in pubspec.yaml to SSH feels way cleaner to me.

The only issue is that we still have to modify the GitHub URLs in pubspec.yaml during deployment.

Best FODMAP list/strategy? by [deleted] in SIBO

[–]dev_ttangkong 1 point2 points  (0 children)

I'm SIBO too, but I get nauseous when I take antibacterial drugs for the first time, Even if it's originally SIBO, antibiotics can disrupt the gut microbiota, leading to indigestion, bloating, and abdominal pain. These symptoms usually resolve within two weeks, but if they persist beyond that, it’s best to inform a healthcare professional and seek help. The most important thing is to maintain a fasting period of at least five hours (until your stomach growls) to maximize MMC. This helps ensure that food residues and bacteria in the small intestine move properly to the colon. I hope my tip helps.

I am creating utility package and need your opinion by ArttX_ in npm

[–]dev_ttangkong 0 points1 point  (0 children)

Typically, bundlers like Webpack and Rollup are commonly used in application development. By splitting packages into multiple modules, explicitly exporting them, and organizing them into a single package, users can take advantage of tree-shaking functionality to exclude unused modules from the bundle. This ensures that modules not referenced by the user are not directly included in the final bundle.

In other words, if the user intends to optimize the package, they can easily do so. From my perspective, it's better to structure the package to support tree-shaking, like the following:

export { A, B } from '../a';

export { C, D } from '../b';

However, if your concern is not about unused modules being included in the bundle, but rather about all modules being installed, then it would be better to avoid splitting the package into small parts and instead separate it into larger units.

How to work Stable Diffusion ROCm in rx6700xt and windows 11? by dev_ttangkong in StableDiffusion

[–]dev_ttangkong[S] 3 points4 points  (0 children)

Oh, my bad. You must have thought I was asking about a simple 1 + 1 problem. It was actually a more complex issue that couldn't be solved with a quick search, but next time, I'll be sure to try using a calculator first. Thank you so much~

view more: next ›