I'm a Google Developer Expert in Dart and Flutter (one of 12 in North America). I have 45 years of experience with backend, web, mobile, devops, and training.
I wish you’d do something similar for DartNative—something like bloc_signals_dn for dartpub.dev. I’m not affiliated with DartNative or its codebase; I just needed what they’re building, and I’m missing your packages there!
I'm a Google Developer Expert in Dart and Flutter (one of 12 in North America). I have 45 years of experience with backend, web, mobile, devops, and training.
One of the foundational design choices of the core bloc_signals package (along with its state primitives, transformers, replay engine, and serialization adapters) is that it is 100% pure Dart—it carries zero Flutter SDK dependencies. Because it relies purely on native Dart signals and streamless concurrency primitives, it compiles and runs anywhere the Dart runtime or AOT compiler targets (CLI tooling, native server backends, web via Jaspr, and embedded runtimes).
I haven't tested it directly against DartNative / dartpub.dev yet, but in principle, core bloc_signals should work out of the box in pure Dart environments. What specific bridges or bindings would you find most useful for your DartNative workflow? (For example, C/Obj-C interop event dispatchers, native threading memory isolation, or FFI lifecycle hooks?)
Yes, I’m referring to bloc_signals_flutter. We only need a few minor changes to make it work with DartNative. Please allow me to make those changes and publish the updated package on dartpub.dev.
I'm a Google Developer Expert in Dart and Flutter (one of 12 in North America). I have 45 years of experience with backend, web, mobile, devops, and training.
Yes, I'd be interested to see a pull-request. Or, if you want to release an independent package, be my guest. (I think we could even link your repo into our final publication health check to make sure we didn't break your package.)
superb
Glad you liked it! Now that I've solved shopping carts, infinite scroll, and overall architecture, what would you like to see next?
I wish you’d do something similar for DartNative—something like
bloc_signals_dnfor dartpub.dev. I’m not affiliated with DartNative or its codebase; I just needed what they’re building, and I’m missing your packages there!That is an intriguing direction!
One of the foundational design choices of the core
bloc_signalspackage (along with its state primitives, transformers, replay engine, and serialization adapters) is that it is 100% pure Dart—it carries zero Flutter SDK dependencies. Because it relies purely on native Dart signals and streamless concurrency primitives, it compiles and runs anywhere the Dart runtime or AOT compiler targets (CLI tooling, native server backends, web via Jaspr, and embedded runtimes).I haven't tested it directly against DartNative / dartpub.dev yet, but in principle, core
bloc_signalsshould work out of the box in pure Dart environments. What specific bridges or bindings would you find most useful for your DartNative workflow? (For example, C/Obj-C interop event dispatchers, native threading memory isolation, or FFI lifecycle hooks?)Yes, I’m referring to
bloc_signals_flutter. We only need a few minor changes to make it work with DartNative. Please allow me to make those changes and publish the updated package on dartpub.dev.Yes, I'd be interested to see a pull-request. Or, if you want to release an independent package, be my guest. (I think we could even link your repo into our final publication health check to make sure we didn't break your package.)
Hello, my name is Hokai from hong kong.
I am looking for a long-term partner.
If you are interested, please contact me.
Thank you.