Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Erik LaBianca
    @easel
    Ok sounds good. My hunch is that proxies in javascript would need to be handled differently. I’ll reach out here once I have a second to poke at it.
    Artyom Kozhemiakin
    @akozhemiakin
    Hi guys! I wonder if there is any automatic way to inject multiple dependencies implementing the same interface (extending the same trait) in a form of a List (or Set, or other collection, or even shapeless HList) using macwire? I'm talking about some functionality more or less similar to the multibinding in Guice
    Artyom Kozhemiakin
    @akozhemiakin
    Ok, it seems that I eventually encountered what I'v searched for in the source code and it is "wireSet" method. Also it is not documented and I'm not quite sure how to use it properly.
    Artyom Kozhemiakin
    @akozhemiakin
    I'v created the pull request to add HList injection support: adamw/macwire#88
    Ilya Epifanov
    @ilya-epifanov
    Hi guys, can I wire some parameters with macwire but provide remaining ones with implicits manually?
    Like this: def strategy1()(implicit staticsContext: StaticsContext, param1: Param1) = wire[Strategy1]
    class Strategy1 @Inject() (val service1: Service1, val service2: Service2)(implicit staticsContext: StaticsContext, param1: Param1) { ... }
    Or should I separate this into two classes?
    Ilya Epifanov
    @ilya-epifanov
    Ok, I've tested this, it works fine:)
    Rafal Wachol
    @charafau

    hello! I am doing some programming with scala on android and I thought about using macwire. Everything works nicely but I got stuck with injecting class which depends on the other one extending module. Example:

    class ChatPresenter(chatContractView: ChatContractView) extends ChatContractPresenter { }
    
    trait ChatModule {
      import com.softwaremill.macwire._
    
      lazy val presenter: ChatContractPresenter = wire[ChatPresenter]
    
    }
    
    class ChatFragment extends BaseFragment  with ChatModule { pesenter. ..... }

    So I want to use ChatPresenter in ChatFragment. How can I achieve this ?

    Rafal Wachol
    @charafau
    ok, I resolved my problem, in case someone will have the same problem, I'm leaving solution here:
    trait ChatModule {
      import com.softwaremill.macwire._
    
      def presenter(chatContractView: ChatContractView) : ChatContractPresenter = wire[ChatPresenter]
    
    }
    
    class ChatFragment extends BaseFragment
      with ChatContractView
      with ChatModule {
    
      val chatPresenter = presenter(this)
    }
    Marius B. Kotsbak
    @mkotsbak
    Hi
    Maybe a strange question, but as Macwire is at compile time, is it possible to DI types?
    Rafal Wachol
    @charafau
    what do you mean
    Denis Mikhaylov
    @notxcain
    Typelevel DI, sounds cool, even though I do
    Marius B. Kotsbak
    @mkotsbak
    I mean something like "type DB = PSQLProfile" where MacWire replaces PSQLProfile with the correct type that is later used directly
    Adam Warski
    @adamw
    @mkotsbak I'm not sure how that could work. Maybe you could paste a snippet which would demonstrate what you'd like to have?
    Marius B. Kotsbak
    @mkotsbak
    Will do
    In the mean time I got it to blow up completely: exception during macro expansion:
    [error] scala.reflect.macros.TypecheckException: not found: value actionBasedSQLInterpolation
    Marius B. Kotsbak
    @mkotsbak
    at com.softwaremill.macwire.TypeCheckUtil.typeCheckExpressionOfType(TypeCheckUtil.scala:58)
    Marius B. Kotsbak
    @mkotsbak
    Hmm, yes it is trying to DI some type I am supposed to declare myself
    Marius B. Kotsbak
    @mkotsbak
    @adamw I am still unsure how I get a lazy val to be picket up by MacWire instead of it trying to contruct the class manually
    Tried @Module
    Adam Warski
    @adamw
    @mkotsbak some simple snippet of what you are trying to do would be helpful :)
    Marius B. Kotsbak
    @mkotsbak
    Well, I see that it is needed to declare the dep using constructor parameters too, but what I have is a trait
    I'm struggeling with this one:
    DatabaseSetupAndTeardown.scala:30: Cannot find a public constructor nor a companion object for ...DatabaseProfile
    at lazy val dbProfile = wire[DatabaseProfile]
    Which is declared here:
    @Module
    trait TestModule extends BackendCoreModule {
        override lazy val dbProfile = H2TestProfile
    }
    But DatabaseSetupAndTeardown is a trait and can't be a class
    Marius B. Kotsbak
    @mkotsbak
    A workaround is to use a cake here instead. It compiles if I let DatabaseSetupAndTeardown inherit from TestModule, but then I don't use MacWire...
    Adam Warski
    @adamw
    I'm not sure what's the full example, but macwire only helps you to wire classes using constructor parameters
    it's mostly a convenience tool so that you don't have to write the constructor call yourself
    Marius B. Kotsbak
    @mkotsbak
    Yes, but shouldnt the wire macro work too?
    Mark Grey
    @DeaconDesperado
    I'm probably misunderstanding macwire in a very simple way, but if i have a collection of "interfaces" represented as traits, and want to "wire" the implementation of those traits in (think like guice here I guess?), how would that work with macwire? If I'm understanding the example in the README correctly it seems to be wiring only the implementations themselves.
    Rafal Wachol
    @charafau
    you simply wire implementation like wire[DatabaseDaoImpl]
    in tests you can make TestModule which will extend MainModule and override that wire with some MockDatabaseDao
    Greg Silin
    @gregsilin
    Howdy.. is there a way to make circular dependencies work with macwire? I'm on macwire 1.0.x, Scala 2.11, Play 2.3.x although I could upgrade to macwire 2.x if necessary. In my case, I have service A depend on service B & service B depend on service A, so I would expect other people have hit this situation. Assume that in my case it's a large codebase and I can't quite refactor to remove those cases
    Greg Silin
    @gregsilin
    Solution hinted at here fixed the issue for me adamw/macwire#18
    will appreciate suggestions on better approaches, if there are any
    Joseph Price
    @joprice
    what do you consider the best practice for disambiguating primitives used to configure a service with macwire? (tagged types, value classes, wrapper objects representing a group of config fields, etc)
    Adam Warski
    @adamw
    @joprice macwire or not, I would say that getting more type-safety is usually beneficial, esp when there are many primitives around :) All three options you mention have different use-cases, e.g. type-tagging has the benefit that you can use any existing type as a tag so I've used that to tag the Long id of an entity with the type of the entity. Otherwise I'd say some kinds of wrapper objects
    Joseph Price
    @joprice
    Thanks! I came to the same conclusions but wasn’t sure if you had come up with other patterns I wasn’t yet aware of.
    Marius B. Kotsbak
    @mkotsbak
    How to override a single dependency with a mock in the tests?
    Marius B. Kotsbak
    @mkotsbak
    I.e I have a module with all deps setup, but I want to override it with some local dependency that is a mock
    Adam Warski
    @adamw
    if the module is e.g. a trait, just override that single dependency
    Marius B. Kotsbak
    @mkotsbak
    Hmm
    I have the test class extended from the module trait
    I guess it is impossible to override it for just one test then as the wiring happens at compile time
    Adam Warski
    @adamw
    right, then you have to instantiate the module trait for each test
    which kind of makes sense, as you want a different dependency for each test in your scenario