jezell.bsky.social
Software Designer. Currently hacking: AI, Agents, Flutter
74 posts
78 followers
73 following
Regular Contributor
Active Commenter
comment in response to
post
Just doing my weekly bsky check 😂
comment in response to
post
I could make some, but I thought everyone came here to get away from people like me. I don't want to crash the party 😂
comment in response to
post
Very cool. Tailscale really is awesome for distributed teams.
comment in response to
post
So awesome
comment in response to
post
Yeah I love Flutter. It's my favorite framework. I just want it to be better!
comment in response to
post
I should have said Controller is a "Change Notifier" not "Value Notifier". Extra value prop is weird for the controller.
comment in response to
post
Two options:
1) In simple cases the controller is just a value notifier because that's all you need
2) In more complex cases, the controller publishes events and allows the user to subscribe to them (either via a Stream or controller provided subscription mechanism).
comment in response to
post
Well it is, but if I see a widget with a bunch of value notifiers for every property I'm gonna think someone as putting way too much logic in their widget and they should have just built a controller class. It's hard to pass around groups of value notifiers, easy to pass around a controller.
comment in response to
post
They are decent for theming, media queries, and UI framework concerns. Still tend to fall apart with overlays but the less of them you have to manually copy into a new tree when you need screenshots or use overlays, the better. Also can be an escape hatch when you don't own all the code.
comment in response to
post
FFI isn't supported on web where these issues are really problematic. I actually had to contribute changes to the web engine to make it possible though.
comment in response to
post
Maybe if you want to handle those cases. In practice keys tend to be an easier solution to handle property changes in stateful widgets though. How much code do you want to type for something so basic?
comment in response to
post
The late final is also bound to the lifecycle. it won't get executed until it is accessed from build since late is lazy. Since a promise can't return in the current run of the event loop, the result will be returned after the first build either way. So in practice it's almost identical.
comment in response to
post
I don't mind streams for data from servers, but for event streams I don't like the complication compared to JS EventEmitter.
I avoid ValueNotifiers because they are overly complicated to use for what they do. Controllers can definitely use ChangeNotifier if you don't need granular notifications.
comment in response to
post
Flutter ShadCN is pretty awesome. Not as complete as the JS version yet, but it's got a lot of the stuff we need in the box.
For everything else we roll mix.
comment in response to
post
Introduces runtime errors, doesn't play nicely with overlays (which some frameworks introduce), hides dependencies, and makes init / teardown a mess if your inherited widget needs any kind of subscribe / unsubscribe or you have more than one inherited widget referenced in your widget.
comment in response to
post
Well what I did was rewrite video_player_web, livekit, and everything we use to not use platform views, and then not introduce any of our own 😂
comment in response to
post
Unless you actually want your app to use Material styles there is a lot of friction changing the way it looks. Even if you want to use Material there is a lot of friction since Material doesn't ship things like Material Symbols and often doesn't conform to the latest material guidelines that well.
comment in response to
post
I've avoided BloC, GetX, Riverpod, and all of those weird state management packages from day one, so I should probably add that to the list since apparently that's not obvious to everyone 😂
comment in response to
post
Avoid:
1. Importing material.dart or using any material widgets
2. Inherited widgets
3. Platform views (HtmlElementView / VideoPlayer)
4. Too much logic in stateful widgets (controllers instead)
5. RawImage
8. Overlays (use OverlayPortal)
9. go_router
comment in response to
post
Agents with function calling. Zapier is old school.
comment in response to
post
Betas were more stable than 3.26, time to try out the release
comment in response to
post
This really needed to happen!
comment in response to
post
The o1 models appear to basically just be refined versions of the 4o model that help avoid bad plans and package up that for loop into something that works out of the box with a lot less work. You can't even have a system prompt (which is needed for 4o agents), because they use it for their loop.
comment in response to
post
Hard to have any real discussion on bsky because of the crappy character limits. At a high level, an agent needs to be able to come up with plans, then call functions while executing the plan. The 4o models can be used for some of those parts, but are rather low level and brittle for building agents