@@faisalmushtaq2287 I would use it EXACTLY the same as I'm using it with provider, which is why I'm not switching. I actually don't even need provider. I just need the ui to update when notify is called. That's literally all I need it for :) So swapping to riverpod would be a waste. I won't use any of the new functionality in it.
Such perfect timing for me, as the next Todo on my list after I finish the current feature was to clean up all the theme stuff scattered through my app. I think you did a good job of balancing showing us a couple of examples for each part, but not tediously typing out everything during the vid. As always, loving your content and grateful for all your efforts! 😁
Thanks Tyler! And I appreciate you always giving me great feedback. I tried to make sure I'm going through repeat work over and over so I'm happy to hear I found the right balance. It's a good way to organize everything in your code base.
What a great video, I really learned alot about how a professional structures and seperates/encapsultes the UI from the functionality. I am going to try to mimic your structure in my next Flutter project.
Hey. It would be great if you did a video comparing the advantages and drawbacks of using GetX vs. the (Provider + Get_it) combination on your channel, for state management and dependency injection. I recently explored GetX and found it to be close to a combination of the singleton pattern with features from Bloc and Provider. I would go as far as to say it somewhat resembled the finesse of Redux, minus the boiler plate. Would be great to have your point of view on it.
Hey, I don't think that video would really provide much value. If I had to use it, it would still be wrapped the same way as I wrap provider. The only thing I don't like about it is that it makes your entire code base dependent on it. So either way it's used, whichever one is used I wouldn't be dependent on it directly. I'd wrap it up in a View ViewModel implementation. To end it off, I think getX is great. If you like it you should definitely use that. Especially if you understand it better than my approach.
@@FilledStacks Appreciate your honest response. Although I do prefer to de couple my service locator with my state management (similar to the approach you follow on the channel) which gives me more control, my organisation has recently chosen to migrate to GetX. Was wondering what the cons would be of relying solely on such a framework. I'm thinking if implementing a new feature at some point goes south, we might have to use GetX with a combination of another solution anyway. I guess time will tell.
@@aakashr79 I see I see. If you abstract it away it should be fine. I'm always concerned about unit testing as well which some packages don't allow because it's not pure dart. So make sure you can write real unit tests then you should be in a good spot with whatever you choose. as long as your business logic tests can run without starting flutter you're in a good spot.
Hey hey, the type of app you build doesn't make a difference. all apps are kind of the same. You get data from an api, you show that on screen. You should use the language that you're the most comfortable with. Any app is fine for any modern framework.
I extracted the design system from UI in a file that I bought at the beginning. I just compiled to total design system from it but didn't design the all the UI
@@FilledStacks No, basically I want to covert html elements to flutter widgets, there is a lib called flutter_html, but I want without using it to achieve this
@@chorauoc139 well you have to do exactly what that package does. Open their code up, read what they're doing and rewrite that. If it's not for practicing it would be a very bad idea to spend 3 weeks on something that's already been built.
Hi, I'm new in flutter. Since this video published 2 years ago, can I use the way you explain in video? Or maybe there's new way to create design system? Thank you.
Hi, there's no new way. This is a general approach that you will probably use forever, it's how we do it. But with new language features you will always be able to write some things using a different syntax.
hi. how do you handle different screen size? currently I am using flutter_screenutil so my UI is responsive on different phones. I wonder how you do it in your app?
No it does not. If you want a spearate design you can check the platform value and style differently but all clients I've worked with want their design to match on iOS and Android.
@@nicholai9266 For some things yes. If you use the built in flutter widgets then it'll do that. If you style it yourself that style will reflect the same way across all pplatforms including web, desktop and watch.
@@FilledStacksNow it's crystal clear to me. I keep wondering on how will the ios look like without having an actual device to design a native-like in a iphone rather than using a android feels app in a body of an iphone. Thank you so much. 😊👑
will there be phone authentication in the app? I think it will be good to have instead of just username/password or google. logging in by mobile number would be very handy for the user
Yup, we'll add that down the line. I want to start building functionality for the app so these will be the only authentications we have for now until we have some decent functionality built.
If we are creating package then what to do when building apps for production I mean do we need to publish the package first or we can build the production app with in dev mode package?
@@devsbuddy No you don't you can reference it locally when developing and when publishing. The code will just get compiled into the app the package doesn't need to be live.
I can not, I bought the file. It wouldn't be fair to the creator of it if I share it instead of directing people to his file. On the written tutorial there's a full image of the design system that I extracted.
No it does not. It's pretty complicated for not a lot of pay off at the moment. We're building a web application so we'll probably re-write the navigation to use navigator 2.0 and then we'll migrate over making sure our api stays the same.
@@FilledStacks also i see your stacked architecture supports getx now for navigation! I’ve not used it for a while so I thought we had auto route ! So my question is does the current architecture support url driven navigation like in web? Doing RND for web project and I really don’t want to move away from your architecture!
@@abdula5842 We've used get navigation from day 1. Never used some else. The only thing that changed is that we don't use the new autoroute. I forked the package at v0.6.9 and built it into stacked because v1 wasn't going to be compatible with our way of developing. About the url nav i don't know. Haven't been doing a lot of flutter web. But if autoroute supported it before v1 then we do as well.
@@FilledStacksi looked at get and saw it supported it ! Do you think the latest stacked architecture supports it as well by default since we use get under the hood?
Hey, i bought the design. I don't think it'll be fair to share it. When I shared the original link somewhere in the comments where you can go and buy it too.
Hey hey, if you want to become a GDE your location doesn't matter. You need to be a champion of the framework. Teach, share knowledge, use it, help others, contribute if you can, grow our community and make it a good thing to be apart of.
Hey, Why should we have the package for design files? I do it like having one dedicated folder containing design files and in the file I create static const variables in a class like this 👇🏻 Why should we have the package instead of this approach, in this approach we can have performance benefits of using const. class AppColors { /// Primary Color /// #F64B67 static const pink = Color(0xFFF64B67); ... } // If it's styles file class AppStyles { static const title1 = TextStyle( fontSize: 48, fontWeight: FontWeight.w700, color: AppColors.typeDark, letterSpacing: -1, ); ... } // Access like this Container(color: AppColors.pink); Text("Hello", style: AppStyles.title1);
We also do that in our apps without wrapping it in classws. As I mentioned in this video, this UI has to be used in 3 different apps. And we don't want to repeat any of the UI code. So the best option is in a package where we can maintain it in a single place for all 3 apps.
