Iglistkit: [Questions] Architecture and DI Container in IGListKit

[racer1988]

Hello,

I would like to ask some questions to the community here because we are struggling a bit to understand some topics and connect them with IGListKit.

I am aware that these topics are not related to IGListKit code, but more architectural questions and software engineering knowledge, but I hope this could help creating some know-how around IGListKit and maybe transform this into a best-practices section later on with a PR.

1- Is IGListKit written on top of a specific architecture? (eg: Is it following MVVM?) I am not clear if it is and it would be interesting to understand it. Does this impact the use of it inside any other architecture, due to the requirements of the patterns behind it?

2- How would you suggest to use a Dependency Injection framework with IGListKit AdapterDataSource to initialise all section controllers?
The Adapter needs to create SectionControllers, and using a dependency injection framework, a container is going to resolve this controllers and the sub-dependencies.
Should the datasource own this container, even if it is a singleton? (but then, how do we test our datasource?)
or should the datasource delegate everything to a factory instead? (but then you don't test factories?)

[rnystrom]

1- Is IGListKit written on top of a specific architecture?

IMO pigeon-holing architectures isn't useful. I wouldn't say we follow any single strict architecture/pattern, more that we follow a few guidelines that make our code easy to maintain & test:

• Inject dependencies instead of rely on global state (unless where it aides the API)
• Decompose objects so they have a single-responsibility. We're not perfect here, but do a pretty good job.

How would you suggest to use a Dependency Injection framework with IGListKit

I'm not sure I'd suggest using a framework for dependency injection _at all_ 😅

I've never seen a DI framework that doesn't result in code bloat and hidden magic. At Instagram, we just write object initializers w/ lots of parameters. Sure, they get long, but its stupid-easy to figure out what is happening.

You can definitely do any type of initialization-dependency-injection w/ Section Controllers that you want. Just init the controllers in the adapter and pass in w/e stuff you want (we do this in Instagram _all the time_).

a container is going to resolve this controllers and the sub-dependencies

I'm not sure how this works or what it does, but again I would personally avoid it.

Should the datasource own this container, even if it is a singleton?

No way, I would never, ever, ever make a data source of _anything_ a singleton. Global, mutable state = bad time.

or should the datasource delegate everything to a factory instead (but then you don't test factories?)

We create separate data source objects at Instagram that handle all of this. We initialize the data sources w/ w/e dependencies that are required by the section controllers it ends up initializing. It keeps the "flow" of dependencies one way, and eliminates any need for global state.

Not totally sure I follow the "don't test factories". What stops them from being tested? If they are stateless the tests should be relatively easy, right?

[racer1988]

@rnystrom Thanks for the info and your view on it.
I am exploring the world of architectural decisions/Frameworks/Container vs No Container trying to improve my codebase and it is always helpful to have some information from other developers, especially when they are working on a big app that is used by a lot of people and works (and it maintainable and scale)

For sure I guess the best path to follow, instead of pointing different arch/framework is going SOLID, as you were highlighting

I agree with the constructor dependencies being enough, sometimes however when you need something very low in the stack, you end up with a guy been passed from root to bottom, being never used in the middle. (or maybe I am approaching this wrong :D)
and that global state is bad 😡

Regarding factories, I was pointing out that, if this factories use the container, so they have a singleton inside/global state, then they get harder to mock/test

[racer1988]

@rnystrom I actually have another question, regarding how you use IGListKit in Instagram.

Let's say my Section Controllers are fetching data, need to do some calculation or whatever else.

If I want to use DI and split responsibilities, then the datasource needs to be aware and get injected with all section controller requirements.

Then if I need to add one section controller to my app, I need to change the initialiser of every single layer that is above the datasource and fill the datasource initialiser with tenths of arguments.

This is something I cannot wrap my head around and brought me thinking that a DI Container framework is needed.

How do you handle the generation of components? They are in the root of the app, and injected down everywhere (and in this case how you solve the missing encapsulation problem)?

[heumn]

Ryan has a very important point here I want to repeat

MO pigeon-holing architectures isn't useful. I wouldn't say we follow any single strict architecture/pattern, more that we follow a few guidelines that make our code easy to maintain & test

Keep researching. Get inspired. Discuss with other developers. Grab onto the things you think make sense and forget the rest. You are clearly on a good path and do not get frustrated because you havent really found how you can solve _all_ of your architectural problems with something like dependency injection... because you wont 😄 There will _always_ been pros and cons. Shortcuts _will_ be made. There are no such thing as a project with a perfect architecture. If someone tells you that, I call liar or that project hasnt shipped. Hell, there are some things about IGListKit that I would consider break some best practices. Do I still use love it? Absolutely. The pros clearly outweight the cons.

A bit off topic but if I were to suggest any talks / readings I would say read up on some light functional programming topics in swift, VIPER / VIP / MVVM and start using the small things you like. Watch Garys Boundries talk. Read Jereds recent blog and keep reading how you can use dependency injection in your Swift projects 👍 Over time you will improve. A lot. But even after _many_ years in this industry, most of us (especially me) feel like complete nub multiple times a day 💃

I would gladly try to help you (if I can) with any more questions, just hit me up on twitter 💯

Maybe this issue could be closed as it is... far beyond the scope of IGListKit? 🤔

[racer1988]

@heumn Thank you 😄

That is exactly why I asked some question here ehe, to discuss a bit on this open community and get some feedbacks! I am going to jump into your links and keep trying to find out what works best.

There is always so much to learn in Software Engineering, always, too much 🤣

Thanks again, I will close this issue

[heumn]

My pleasure :)