Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relations between features #23

Open
sbitab opened this issue Apr 15, 2020 · 3 comments
Open

Relations between features #23

sbitab opened this issue Apr 15, 2020 · 3 comments

Comments

@sbitab
Copy link

sbitab commented Apr 15, 2020

Hi
How can I use widgets or pages of another feature?

Example:
For example, I have an authentication feature, I want to use the login widget of this plugin in the feature of my store, how should I do this?

If I import the widget into my storeframe, the modular structure will be lost, right?

@ghezeli
Copy link

ghezeli commented Apr 15, 2020

hi
i have same problem
please help

@dominikseger
Copy link

I was asking me the same. If multiple features using the same widget, should it be in the core folder, because it's some kind of "global" then? There are so many cases where I need to use models,bloc pattern etc. across features that I don't know if this architecture is really gonna fit for me(or maybe I didn't understand it yet).

For example:
I have a HomePage and SettingsPage, both of them would be a feature.
On the HomePage there is a cog Icon which lead to the SettingsPage. If there is an update available, the cog icon on the HomePage should get a batch and in the SettingsPage there must be a button shown. I would need to share the the state(bloc logic) between them to archive this.

So should HomePage and SettingsPage should be one feature to share state or should this bloc be global under the core folder?

I appreciate your work @ResoDev, maby you finde the time to answer.
Keep up the great work :)

@mikeandersen
Copy link

FWIW, in his newer DDD course, he recommends a different folder structure where features are nested under folders for each architectural layer, instead of the other way around. From Flutter Firebase & DDD Course:

I'm the first to admit that the folder structure outlined in the Clean Architecture course is a pain to deal with. With DDD, we're going to take a different approach.

Layers will hold features, not the other way around. This will still keep the code readable but, most importantly, it will ensure that adding more features and sub-features is going to be a pure bliss!

[...]

All in all, we can mix and match the dependencies in between features as long as we keep true to the dependency flow outlined in the diagram above (domain layer has to have ZERO dependencies on other layers).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants