flutter_use: a gallery of Flutter techniques rather than a package

A collection of tricks, and the readme says so

The repository description is two lines in two languages, and both say the same thing: some tricks used by Flutter, and the tricks used by Flutter. The readme frames each entry as a technique every developer should know about, and every technique is paired with a long form write up hosted on a Chinese developer blogging platform.

That is the correct mental model for the project. There is no library here, no package to add to a pubspec, and no API to call. There are demonstrations, each one a small working application that shows a specific approach, and a directory tree in the readme that tells you where each demonstration lives.

The topics are the ones a Flutter developer argues about. The first is the nested widget problem, with an article about improving it and a demonstration that imitates a desktop page layout of a Chinese audio platform, which is a realistic test because that kind of page is where the nesting goes wrong. The second is dialogs, with a write up about the pain points of Flutter dialogs and a demonstration of a low intrusion dialog solution, where SmartDialog is the library being demonstrated. After that come three state management demonstrations, GetX, Provider and Bloc, each with a usage article and a source analysis article.

The licence is MIT and the primary language is Dart. What you take from the repository is code and understanding, not a dependency.

The directory tree is the index of the techniques

The readme documents where everything lives with directory trees, and the pattern is consistent. Everything sits under lib, then a module directory, then a function directory, then the demonstration itself.

The GetX section shows the shape in full.

│  │  │  │  ├─auto_dispose
│  │  │  │  ├─counter_binding
│  │  │  │  ├─counter_easy
│  │  │  │  ├─counter_high_get
│  │  │  │  ├─counter_rx
│  │  │  │  ├─easy_x
│  │  │  │  │  ├─easy_builder
│  │  │  │  │  └─ebx
│  │  │  │  ├─easy_x_builder
│  │  │  │  ├─easy_x_ebx
│  │  │  │  ├─jump_page
│  │  │  │  │  ├─jump_one
│  │  │  │  │  └─jump_two
│  │  │  │  └─widget

Reading the names tells you what the demonstration covers. There is an auto dispose variant, a counter written with a binding, a counter written the simple way, a counter that uses the higher level get function, a counter built around reactive values, and an easy_x example with a builder and an ebx variant. There is a jump_page directory with a single and a two step navigation example, and a widget directory at the end for shared components.

The Provider tree follows the same naming logic with counter_easy, counter_high, custom_builder, several easy_p variants including a global one, a span_page with two screens, and a test_notifier directory. The Bloc tree adds a common widget directory, a bloc directory with a counter_bloc and a counter_cubit, custom_builder, a stream directory and the same two screen span example.

So each library is demonstrated at several levels of sophistication, which is what makes the collection useful for comparison rather than merely for browsing.

The dialog and nesting examples are the unusual ones

The state management demonstrations are the expected part of any Flutter repository, and comparing GetX, Provider and Bloc in one place is genuinely useful because the same counter application appears three times under different idioms.

The dialog example is the more interesting one. The linked article is titled as a solution to the various pain points of Flutter dialogs, and the description of it in the readme is a concise, capable dialog solution with very low intrusion. The demonstration directory is named smart_dialog, which identifies the library being demonstrated.

That phrase about low intrusion is the whole argument. A dialog layer built on the standard showDialog and Navigator API tends to leak into the widget tree, and the usual workarounds add wrappers, a global key, or a custom navigator, each of which has to be threaded through the application. A solution that keeps the call site to a single call and does not require the surrounding widget tree to be wrapped is the thing most teams end up building for themselves, and having a working example saves a day.

The nested widget example serves the same purpose for layout. A page that imitates a desktop audio application is a deliberately bad case for the widget tree, with lists, headers, tab bars and content areas, and the demonstration shows a directory structure that keeps the widget hierarchy flatter than the naive version.

Running the demonstrations: the web gallery and the Windows quirk

The readme publishes an effects page, and the web build is what it points at. The compiled web code and its assets live in the docs folder, and the GitHub Pages path is set to docs, so the site is served straight from that directory.

That means the fastest way to see any of the techniques is the web build, and the repository ships a publish_web.sh script at the top level alongside the platform folders for android, ios, web, linux, macos and windows, plus a pubspec.yaml, an analysis_options.yaml and a test directory.

There is one environment wrinkle that the readme handles in detail, and it is worth knowing before you build. Because the project depends on window_size, the build or the run can fail on Windows, and the fix is a system setting rather than a code change. On Windows 10 you go to Settings, then Update and Security, then Developer options, and enable developer mode with the option to install apps from any source, including loose files, turned on.

That is a small illustration of what this repository is: it is a playground that pulls in third party packages, and the cost of that is occasionally a platform setting. For a project that will be shipped, those dependencies are decisions you would make deliberately, and the readme shows you one of them.

Packaging commands for Android, iOS and web

The readme records three build commands, and each one differs from the default in a way that reflects a deliberate choice in the demonstration code.

  - flutter build apk --no-shrink
  - flutter build ios --release
  - flutter build web --web-renderer canvaskit

For Android, R8 shrinking is turned off, which is a common choice in a demonstration because shrinking can strip code that is only reached reflectively, and a state management library that resolves a controller by name is exactly the kind of code that shrinking can break.

For iOS, the release build produces an .app and the packaging itself is then done in Xcode, which is the normal path for iOS distribution anyway.

For the web, the CanvasKit renderer is selected rather than the HTML renderer. That choice matters for the gallery in particular, because the CanvasKit renderer draws the same way on every browser, so a screenshot from the site looks the same as a screenshot from a desktop application, and text rendering is consistent.

These are demonstrations rather than production configurations, and the fact that the readme calls them out is a hint about the audience: someone learning the techniques and someone copying a build command they have seen work.

Where flutter_use is the wrong tool

Three things this repository is not, and each one matters.

It is not a package. The pubspec.yaml belongs to a Flutter application, not to a published library, and the repository has no GitHub releases, so there is nothing to depend on and nothing to pin. If your plan was to add it to a pubspec, that plan does not apply, and the realistic use is copying the code out of it.

It is not current documentation. The write ups are hosted on an external blogging platform and describe specific library versions at specific moments, and the demonstrations were written against the state management libraries of their time. GetX, Provider and Bloc all move, and a technique that reads well in an article may have been superseded in the library since. The repository itself has been quiet for a while, with the last push on 2026-08-23, so it will not be updated to match a new release of anything.

It is not a substitute for the libraries themselves. The GetX, Provider and Bloc directories contain demonstrations of patterns; the authoritative explanation of how those libraries work and which API is current is in their own documentation, and the linked source analysis articles are a reading companion rather than a contract.

One more practical caveat. The readme and the articles are in Chinese, and so is much of the commentary in the demonstration directories, so an English speaking reader is relying on the code to carry the meaning. That is workable for a technique you can see in the tree, and awkward for one where the difference between the easy and the advanced variant is only explained in prose.

Editorial conclusion

flutter_use is worth an afternoon for a Flutter developer who wants to see the same counter application written with GetX, Provider and Bloc side by side, or who wants a concrete example of a dialog layer that avoids nested widget code. It is not a dependency to adopt, since it publishes no package and no releases, and it is not a substitute for the documentation of the libraries it demonstrates. Before using anything from it, read the linked write ups to check the technique still matches the current version of the underlying library, and run the web build locally so you can compare the variants in the browser rather than in a screenshot.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. xdd666t/flutter_use on GitHub