DEV Community: YeLinAung

Return a Result From a Route

YeLinAung — Sat, 19 Sep 2026 17:43:48 +0000

Open a screen and wait for one result.

The support route declares result: bool.

Its generated push() returns Future<bool?>.

The support screen tracks whether a message was sent.

The back action returns that value with context.navigator.pop.

The caller shows confirmation only when the result is true.

Docs used: typed route results and the shopping app support flow.

Dust #Routing #Flutter #Dart

Switch the App Language

YeLinAung — Thu, 17 Sep 2026 18:46:14 +0000

Switch the app language without restarting the page.

The shopping example reads the current locale from I18nScope.

The button picks en or my, then calls setLocale.

Widgets under the scope rebuild with the new locale.

MaterialApp uses the generated locale, supported locales, and delegates.

The same controller drives Dust text and Flutter's built-in localized widgets.

Docs used: switching locales and the shopping app language button.

Dust #I18n #Flutter #Dart

Post One JSON Body

YeLinAung — Tue, 15 Sep 2026 18:41:00 +0000

Post one JSON body.

The client owns the request shape.

The generated HTTP client sends it with @Body().

The server reads the same shape with validBody.

Bad JSON shape returns 422.

Bad validation also returns 422.

The handler only runs after the body is decoded and validated.

Docs used: dust_server tutorial, dust_server extraction, and Dust HTTP bodies.

Dust #DustServer #HTTPClient #Validation #Flutter

Find One Flutter Request on the Server

YeLinAung — Mon, 14 Sep 2026 19:43:02 +0000

Find one Flutter request on the server.

That is basic full-stack debugging.

Flutter DevTools can show the app’s network call. The server still needs a way to find the same request in its own logs or traces.

Dust keeps that path explicit.

The Flutter HTTP client can send a header with the request. dust_server tracing can read the standard traceparent header. If it is valid, the server span joins the same trace. If it is missing, the server starts a new trace.

The response also carries traceparent.

So the flow stays simple:

Flutter sends the API call;
the generated client maps the header;
the server records the request span;
the response gives back the trace id.

Do not put secrets in trace data. Use ids that are safe to store.

Docs used: Flutter DevTools Network view, Dust HTTP header parameters, dust_server tracing, and dust_server middleware.

Dust #DustServer #HTTPClient #Flutter

Serve the API and Flutter App Together

YeLinAung — Sun, 13 Sep 2026 17:53:29 +0000

Serve the API and Flutter app from one Dart server.

That is a simple full-stack setup.

The API owns the /api routes.

The Flutter app owns the browser routes, like /products/42.

dust_server can put both behind one router. API routes run first. Anything the API does not claim can fall back to the built Flutter web app.

This matters for path URLs.

If a user refreshes /products/42, the server should send index.html. Then Flutter Routing can read the URL and open the right screen.

The app logic stays split:

server routes handle API work;
Flutter routes handle screens;
the generated HTTP client calls /api;
the same server serves the built app.

This is not server-side rendering. It is one process serving an API and a client-side Flutter app.

Docs used: dust_server web apps, Dust Routing deep links, Dust HTTP clients, and Flutter URL strategies.

Dust #DustServer #Routing #HTTPClient #Flutter

Validate Before and After the Request

YeLinAung — Sat, 12 Sep 2026 17:40:03 +0000

Validate before the request. Validate again on the server.

That is normal app work.

Flutter forms can catch simple mistakes before submit. The server still owns the final rule.

Dust keeps that flow clear.

The request model owns the rule. The Flutter app can call validate() before sending. The server can read the JSON body with validBody(...) and reject bad input before the handler continues.

The user gets a faster error on the app.

The server still protects the API.

The code stays in clear parts:

request model;
Flutter submit flow;
server endpoint;
server response.

Write the product rule once in the model. Use it on the path where the request moves.

Docs used: Flutter form validation, Dust Validation, Dust HTTP clients, and dust_server tutorial.

Dust #Validation #DustServer #HTTPClient #Flutter

Open a Product Link With Dust

YeLinAung — Fri, 11 Sep 2026 18:08:30 +0000

Open a product link in Flutter. Read the product from a Dart server.

That is one app flow.

The server owns /products/{id}. dust_server reads the path value and returns the product.

The Flutter app owns /products/:id. Dust Routing turns the link into a page with an id.

Then the screen uses a Dust HTTP client to call the server. State handles loading, errors, and the loaded product.

The user sees one link.

The code has clear parts:

server route;
Flutter route;
HTTP client;
screen state.

Dust does not hide the app logic. It keeps repeated route, request, and state glue out of the way.

Docs used: Flutter deep links, Dust Routing deep links, Dust route parameters, Dust HTTP clients, and dust_server routing.

Dust #DustServer #Routing #HTTPClient #Flutter

Build a Signup Flow With Dust

YeLinAung — Thu, 10 Sep 2026 18:01:34 +0000

Flutter’s current full-stack developer series is a useful frame for Dust too.

The repeated work is often not one widget. It is the path between the form, request model, API call, state update, and success action.

A Dust version can stay small.

Put form rules on SignupRequest with Validate(). Add Serialize() so the same request can become the HTTP body. Define the endpoint in a Dust HTTP client. Keep the submit flow in a @ViewModel.

The widget stays focused on input and UI. The request model owns validation and JSON. The API interface owns the request shape. The ViewModel owns loading, errors, and the success effect.

That is the point of using Dust across a flow. Not one large abstraction. Just repeated app glue moved into generated files that stay reviewable.

Docs used: Validation, Serde, HTTP Clients, and State Management.

Dust #Validation #Serde #HTTPClient #Flutter

Use Effects for One-Time UI Work

YeLinAung — Wed, 09 Sep 2026 18:16:34 +0000

Flutter shows snackbars through ScaffoldMessenger.

That belongs at the UI edge.

The tricky part is deciding where the event comes from.

If a save action lives in a ViewModel, the widget should not need to own the whole save flow just to show “Saved”.

Dust State has effects for this.

Emit a small event from the ViewModel. Listen with the generated listener widget. Show the snackbar there.

Effects do not change state. They are one-time UI events for mounted listeners.

So the child widget does not rebuild because a snackbar was shown.

Use state for facts that must survive rebuilds. Use effects for short UI work like snackbars or navigation.

Read the Dust State effects guide.

Dust #StateManagement #Flutter #Dart #CodeGeneration

Keep Route Parameters Beside the Page

YeLinAung — Tue, 08 Sep 2026 18:16:15 +0000

Flutter routing gets harder when URLs carry real state.

A product page may need an id, a selected tab, and a list of filter tags.

You can parse those values by hand in the router.

That works, but the route shape can drift away from the page constructor.

Dust Routing keeps them beside the page.

Path parameters match required constructor fields. Other constructor fields become query values.

Dust can parse and restore values such as int, bool, DateTime, and repeated List<String> query parameters.

The page shows what it needs. The generated router handles the URL mapping.

Use this when your app needs deep links that stay close to screen code.

Read the Dust route parameters guide.

Dust #Routing #Flutter #Dart #CodeGeneration

Let Static Translation Keys Create the ARB Shape

YeLinAung — Mon, 07 Sep 2026 18:58:06 +0000

Flutter localization needs ARB files, supported locales, and app bootstrap code.

That setup is clear. The repeated part is keeping message files in sync with the text your app actually uses.

Dust i18n starts from static keys in source.

Use TranslatedText or context.tr with a literal key and default text. The namespace before the first underscore becomes the ARB file name.

Run dust i18n build. Dust creates missing locale files, keeps existing translations, and refreshes the generated Flutter bootstrap.

It does not translate copy for you.

It keeps the message shape close to the code that uses it.

One detail matters: declare each locale directory as a Flutter asset. assets/i18n/ alone does not include the nested locale folders.

Read the Dust i18n keys and namespaces guide.

Dust #I18n #Flutter #Dart #CodeGeneration

Keep API Casing Out of Dart Field Names

YeLinAung — Sun, 06 Sep 2026 17:28:17 +0000

Dart apps read and write JSON all the time.

One small problem appears in many projects.

The API uses snake_case. The Dart model uses camelCase.

You can map every key by hand. That works, but the same casing rule is repeated in every model.

Dust Serde lets the model declare the rule once.

Use @SerDe(renameAll: SerDeRename.snakeCase). Dust applies that rule when decoding and encoding the model.

The field stays displayName in Dart. The JSON key stays display_name on the wire.

That keeps the model easy to read and keeps API naming rules out of handwritten mapping code.

Read the Dust rename strategies guide.

Dust #Serde #Dart #Flutter #CodeGeneration