DEV Community

Wind 1.1.0: a Flutter text field with no MaterialApp

I was building a screen inside a CupertinoApp last week and dropped a Wind text field into it. It crashed. Wind is utility-first styling for Flutter: you write className strings like p-3 border rounded-lg instead of nesting six widgets by hand. But WInput , the one input widget, still leaned on Material under the hood. Outside a MaterialApp it threw. The workaround was ugly: wrap a Cupertino screen in a MaterialApp just to render one field. So in Wind 1.1.0 I rebuilt it. WInput is now Material-free. The problem WInput used to wrap Material's TextField , which needs a Material ancestor for its theme and ink. Drop it under a CupertinoApp or a bare WidgetsApp and you got a layout exception, not a text field. For a utility-first library that is supposed to style anything, depending on Material to render an input was the wrong shape. // Before 1.1.0: a Wind input outside MaterialApp threw. // The workaround was to nest a MaterialApp just to render one field. CupertinoApp ( home: MaterialApp ( home: WInput ( value: email , onChanged: ( v ) = > email = v ), ), ); How 1.1.0 handles it WInput now renders on EditableText with a plain BoxDecoration border. No Material ancestor required. It works under MaterialApp , CupertinoApp , or a bare WidgetsApp . // After 1.1.0: works directly under CupertinoApp, no MaterialApp. CupertinoApp ( home: WInput ( value: email , onChanged: ( v ) = > setState (() = > email = v ), type: InputType . email , placeholder: 'you@example.com' , className: 'p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-sky-500' , ), ); One honest caveat: the long-press selection toolbar and handles need an Overlay in the tree. CupertinoApp and MaterialApp both provide one. Under a bare WidgetsApp with no Overlay , typing, cursor movement, and focus all work; only the selection toolbar is suppressed, instead of crashing like before. className aliases The other change I am happy with is aliases . Wind ships a token catalog, but every project has shorthands that are not in it. Before, an unknown token was a silent no-op (issue #101): you wrote a class, saw nothing, and could not tell why. Now you register your own shortcuts once, on the theme: WindTheme ( data: WindThemeData ( aliases: { 'btn' : 'px-4 py-2 rounded-lg bg-sky-600 text-white' , 'btn-lg' : 'btn px-6 py-4 text-lg' , // aliases expand recursively }, ), child: const MyApp (), ); Then a bare btn works in any widget, including WDynamic (the server-driven renderer), with no extra wiring: WDiv ( className: 'btn' , child: WText ( 'Save' )); Expansion is bounded three ways (a per-chain cycle guard, a depth cap, and a total-output budget), so a circular or fan-out alias map can never hang the parser. Also in 1.1.0 WIcon.foregroundColor : a runtime-dynamic icon color that overrides the text-* class, for state-driven UI. It stays out of the parser cache key, so dynamic colors do not bloat the cache. WInput polish: a readonly state (so readonly: prefixed classes style it), signed-decimal number input that holds on web too, Cupertino-style selection on every platform, dark-mode label pairs on the form widgets, and a disabled field that is genuinely non-interactive. Get started flutter pub add fluttersdk_wind Docs: https://fluttersdk.com/wind Changelog: https://github.com/fluttersdk/wind/blob/master/CHANGELOG.md If you try it, tell me what breaks in the comments.

I was building a screen inside a CupertinoApp last week and dropped a Wind text field into it. It crashed. Wind is utility-first styling for Flutter: you write className strings like p-3 border rounded-lg instead of nesting six widgets by hand. But WInput , the one input widget, still leaned on Material under the hood. Outside a MaterialApp it threw. The workaround was ugly: wrap a Cupertino screen in a MaterialApp just to render one field. So in Wind 1.1.0 I rebuilt it. WInput is now Material-free. The problem WInput used to wrap Material's TextField , which needs a Material ancestor for its theme and ink. Drop it under a CupertinoApp or a bare WidgetsApp and you got a layout exception, not a text field. For a utility-first library that is supposed to style anything, depending on Material to render an input was the wrong shape. // Before 1.1.0: a Wind input outside MaterialApp threw. // The workaround was to nest a MaterialApp just to render one field. CupertinoApp( home: MaterialApp( home: WInput(value: email, onChanged: (v) => email = v), ), ); How 1.1.0 handles it WInput now renders on EditableText with a plain BoxDecoration border. No Material ancestor required. It works under MaterialApp , CupertinoApp , or a bare WidgetsApp . // After 1.1.0: works directly under CupertinoApp, no MaterialApp. CupertinoApp( home: WInput( value: email, onChanged: (v) => setState(() => email = v), type: InputType.email, placeholder: 'you@example.com', className: 'p-3 border border-gray-300 rounded-lg focus:ring-2 focus:ring-sky-500', ), ); One honest caveat: the long-press selection toolbar and handles need an Overlay in the tree. CupertinoApp and MaterialApp both provide one. Under a bare WidgetsApp with no Overlay , typing, cursor movement, and focus all work; only the selection toolbar is suppressed, instead of crashing like before. className aliases The other change I am happy with is aliases . Wind ships a token catalog, but every project has shorthands that are not in it. Before, an unknown token was a silent no-op (issue #101): you wrote a class, saw nothing, and could not tell why. Now you register your own shortcuts once, on the theme: WindTheme( data: WindThemeData( aliases: { 'btn': 'px-4 py-2 rounded-lg bg-sky-600 text-white', 'btn-lg': 'btn px-6 py-4 text-lg', // aliases expand recursively }, ), child: const MyApp(), ); Then a bare btn works in any widget, including WDynamic (the server-driven renderer), with no extra wiring: WDiv(className: 'btn', child: WText('Save')); Expansion is bounded three ways (a per-chain cycle guard, a depth cap, and a total-output budget), so a circular or fan-out alias map can never hang the parser. Also in 1.1.0 - WIcon.foregroundColor : a runtime-dynamic icon color that overrides thetext-* class, for state-driven UI. It stays out of the parser cache key, so dynamic colors do not bloat the cache. - WInput polish: areadonly state (soreadonly: prefixed classes style it), signed-decimal number input that holds on web too, Cupertino-style selection on every platform, dark-mode label pairs on the form widgets, and a disabled field that is genuinely non-interactive. Get started flutter pub add fluttersdk_wind Docs: https://fluttersdk.com/wind Changelog: https://github.com/fluttersdk/wind/blob/master/CHANGELOG.md If you try it, tell me what breaks in the comments. Top comments (0)

Comments

No comments yet. Start the discussion.