Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Haakon Langaas Lageng
    @HaakonL
    For the record, this is my Scene Context
    public class GameInstaller : MonoInstaller { public override void InstallBindings() { } }
    Haakon Langaas Lageng
    @HaakonL
    public class StartScreen : MonoBehaviour
    {
        private GameManager _manager;
    
        // THIS DOES NOT WORK
        public StartScreen(GameManager manager)
        {
            _manager = manager;
        }
    
        // THIS WORKS
        [Inject]
        public void Construct(GameManager manager)
        {
            _manager = manager;
        }
    }
    I'd expect constructor injection to work, but it doesn't. Adding an extra method with the Inject attribute is a workaround, but I'd like to readonly the implementations, just like I do when I work in dotnet core or other c# projects.
    Lavagrados
    @Lavagrados_gitlab
    You should not use constructor with MonoBehaviour, so I think Construct method is fine
    Haakon Langaas Lageng
    @HaakonL
    Ok, got it!
    Thanks.
    Jonathon T
    @zeiphon
    Hmm, so calling container.Inject(myMonoBehaviour); should inject into that object as well as any newly instantiated dependencies right?
    Jonathon T
    @zeiphon
    i'm having an issue injecting Zenject.SignalBus into a dependency
    I have:
    A (MonoBehaviour, in hierarchy) --contains property--> B (ScriptableObject) --calls inject() on--> C (MonoBehaviour) --contains injected field--> D (plain class) --contains injected field--> SignalBus
    A, B and C all also have SignalBus injected, successfully. but when it comes to D, zenject is unable to resolve the SignalBus type?
    Chad Wentz
    @CWentzJaneious
    whats the code look like in D?
    Jonathon T
    @zeiphon
    it's a plain class with [Inject]private SignalBus signalBus;or were you interested in the other class code?
    Chad Wentz
    @CWentzJaneious
    and when are you using the signal bus?
    if it is inside of the constructor then that might be the issue
    Jonathon T
    @zeiphon
    oh, no it's just in a method
    Jonathon T
    @zeiphon
    agh i'm an idiot. I'd forgotten that D was being installed in an editor-time installer from quite some time ago. that was the issue
    Sakari Bergen
    @sbergen

    Does anyone know why the FromFactoryBinderBase component binding methods use new List<TypeValuePair>() instead of BindInfo.Arguments e.g. here https://github.com/modesttree/Zenject/blob/master/UnityProject/Assets/Plugins/Zenject/Source/Binding/Binders/Factory/FactoryFromBinderBase.cs#L150?

    This breaks using WithArguments(...) for any factory producing a Component...

    robertverdes
    @robertverdes

    Hi all. I have a MonoInstaller that inherits from another MonoInstaller:

    class BaseItemInstaller : MonoInstaller<BaseItemInstaller> {  
      public Item.Args Args ; 
      [Inject] public void Construct(Item.Args args) { Args = args }
    }
    class ItemInstaller : BaseItemInstaller { }

    The ItemInstaller is used as a subcontainer factory for Item:

    Container.BindFactory<Item.Args, Item, Item.Factory>()
      .FromSubContainerResolve()
      .ByNewContextPrefab<ItemInstaller>(itemPrefab);

    My assumption is that calling itemFactory.Create(itemArgs) will inject the Item.Args instance into the subcontainer installer. And it works if using BaseItemInstaller, but if using ItemInstaller, it complains:
    ZenjectException: Assert hit! Could not find match for argument type 'Item.Args' when injecting into sub container installer 'ItemInstaller'

    The documentation states that inject methods are called in the order of Base class to Derived class. This can be useful to avoid the need to forward many dependencies from derived classes to the base class via constructor parameters, while also guaranteeing that the base class inject methods complete first, just like how constructors work.

    But this is not the expected behaviour in this case. Indeed, if I duplicate the Construct method in ItemInstaller, it works, and if I log the order of execution, BaseItemInstaller.Construct is called before ItemInstaller.Construct.

    What am I missing? Thanks

    Haakon Langaas Lageng
    @HaakonL
    Any suggestions how I should set up this correctly?
    Container.BindFactory<ILevelController, LevelController.Factory>().AsSingle();
    
    Container.BindFactory<ILevelController, LevelController.Factory>().AsSingle();
    
    public class LevelController : MonoBehaviour, ILevelController
    {
        public class Factory : PlaceholderFactory<ILevelController>
        {
            // Do stuff
        }
    }

    When I call _levelFactory.Create() I get an error:

    ZenjectException: Assert hit! Expected non-abstract type for given binding but instead found type 'ILevelController'

    Sakari Bergen
    @sbergen
    @robertverdes I think this is related: svermeulen/Extenject#7
    Sakari Bergen
    @sbergen

    @HaakonL See how CustomEnemyFactory is used here: https://github.com/modesttree/Zenject/blob/master/Documentation/Factories.md#custom-factories

    PlaceholderFactory is just a mechanism to provide a "typedef". C# lacks such a global alias mechanism, which could look e.g. like this:
    using global FooFactory = IFactory<int, IFoo>;
    so instead we have to do
    class FooFactory : PlaceholderFactory<int, IFoo> {}

    So where you are going wrong is with having // Do stuff in a PlaceholderFactory. You need to implement a separate factory class for that. Note, however, that you don't have to use PlaceholderFactory, but can opt to just use IFactory instead. All you loose in this case is compile-time validation of changes to arguments. But if you have validation in place, I don't see that as a big issue. This is all covered in the docs, btw :)

    Mathijs Bakker
    @Mathijs-Bakker
    Zenject has been deprecated from the asset store.
    Mathijs Bakker
    @Mathijs-Bakker
    For the latest updates and features to the open source DI framework. You are recommended to use the Extenject fork. And for support, use it’s active Gitter channel.