Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
    Stevo Slavić
    hi there
    I'm considering to use macwire
    Stevo Slavić
    init and wiring works nice
    is there any support for other module lifecycle events, like close?
    Adam Warski
    no, you'd have to do it yourself
    as there's no container the module doesn't really have any "managed" lifecycle beyond creation :)
    but you could e.g. add a close() method to your module and there do any cleanup
    Stevo Slavić
    ok, clear, thanks
    maybe a macro or something is possible
    which I could use in close method of a module
    which would inspect all vars of module, and ones which implement e.g. AutoClosable, code would be generated that calls close on them
    and respect order of instantiation, to call close in reverse order
    Adam Warski
    yeah more generally something that returns a set/list of all members that are a subtype of a given type
    I think there's an issue for that ...
    quite old even :) #8
    Stevo Slavić
    could filter, and map in close
    for each AutoClosable, call close
    but without this order constraint, that they get closed inverse to order of instantiation
    Adam Warski
    that could be tricky
    to get the order of instantiation
    and what about a method
    registerForClosing(t: T): T
    in which all values which require closing would have to be wrapped
    that would capture the correct order
    the registerForClosing would add the instance to a list and return it unmodified
    Stevo Slavić
    wire macro could generate those registerForClosing calls automatically, given condition is met that object is a subtype of AutoClosable
    Adam Warski
    true :)
    Yves Müller
    I have usecase question for the wire macro. Most of my Compontents take configuration options (eg. Database name) and other components (eg. Excution context) as a parameter. Now I'd like to use wire in order to provide the components but not the configuration options. Is that even possible?
    My rational is that most of the config options are Strings so that would require to tag them all ... which would result in basically writing down a copy of the config file it self mapping all the paths in the config like "system1.database.name" to tags like "System1DatabaseName"
    Or is there maybe an other way to avoid this? (Maybe a integration with typesafe config to automatically tag values?)
    Adam Warski
    @slomo that's a very good question and I think currently it's not supported. The main problem is that you would like to have some parameters of a component automatically wired, and this causes two issues:
    1. how would you determine which parameters should be provided automatically, and which should be provided by hand?
    2. how would you provide the parameters which a have to provided manually? preferrably in an IDE-friendly way?
    This message was deleted
    integration with typesafe-config would be possible for sure ... maybe something like this:
    • there should be a single dependency of type Config available
    • any parameters marked with with a config path (*) would be looked up in the config
    now there's the question on how you would mark those parameters - with an annotation? but then, what about e.g. default values? any ideas? :)
    Michael McFarland

    I'm a little surprised by the following behavior
    given a type PlatformsPage with dependencies

    class PlatformsPage(platformStore:PlatformStore,platformBackend:(BackendScope[Props,State] => Backend))

    I'm trying to create a factory method (platformsBackend) as a def.

    trait PlatformsModule {
      lazy val platformsPage = wire[PlatformsPage]
      lazy val platformsStore = wire[PlatformStore]
      def platformsBackend(scope:BackendScope[Props,State]):Backend = new Backend(scope)

    This results in an error:

    Cannot find a value of type: [japgolly.scalajs.react.BackendScope[spatutorial.client.modules.platform.Props,spatutorial.client.modules.platform.State] => spatutorial.client.modules.platform.Backend]

    however these versions work

    lazy val platformsBackend:BackendScope[Props,State] => Backend = new Backend(_)
    type BackendFactory = BackendScope[Props,State] => Backend
    lazy val platformsBackend:BackendFactory = new Backend(_)

    can function defs not be used to create factory dependencies?

    Sorry if that's clearly stated, or I'm missing something obvious. Macwire has been a joy to use
    Adam Warski
    defs aren't currently automatically converted to function values, but that would be definitely a good feature to add - could you create a GH issue?
    Michael McFarland
    Sure, adamw/macwire#43