These are chat archives for dry-rb/chat

16th
Aug 2016
Jeff Dickey
@jdickey
Aug 16 2016 03:37
@solnic understood, and agreed wholeheartedly. I think Rails trying to be the be-all, do-all Ultimate Universal Everything™ is what got the Ruby community (etc) into the architectural briar patch we've been in for a decade or so. Just going to take some time to wrap my head around someone else's conventions, that's all, and that's a Good Thing :)
Sean Collins
@cllns
Aug 16 2016 03:51
"architectural briar patch". wow, that's perfect. @jdickey
Nick Sutterer
@apotonick
Aug 16 2016 07:36
i wonder how dry-system would work in existing frameworks such as rails or hanami, @solnic - you said you're going to provide glue code, but doesn't dry-s overlap with those frameworks (e.g. initializer, loader, etc.)?
Piotr Solnica
@solnic
Aug 16 2016 07:55
@apotonick it does a little bit
It could replace railties
Nick Sutterer
@apotonick
Aug 16 2016 07:56
@solnic yeah that's what i figured. but why would you offer that in the first place?
Piotr Solnica
@solnic
Aug 16 2016 07:57
To have a container-based setup with isolated components
Nick Sutterer
@apotonick
Aug 16 2016 08:00
ok, but couldn't you just use dry-container for that?
Tim Riley
@timriley
Aug 16 2016 08:01
you’d need to handle all the dependency management on your own if you were only using dry-container
Nick Sutterer
@apotonick
Aug 16 2016 08:02
yeah, ok, that sounds good to me
i'm thinking about how to leverage dry-s for TRB loading
Tim Riley
@timriley
Aug 16 2016 08:03
-system gives you the load path management, bootable components, convention-over-configuration conveniences like the auto-registration, plus the auto-injection system to tie it all together
Nick Sutterer
@apotonick
Aug 16 2016 08:05
for now, all i need is load paths management and then load models and then concept files (operations, representers, policies, etc.)
what part of dry is responsible for loading files?
Tim Riley
@timriley
Aug 16 2016 08:06
dry-system’s injector will require individual components for you automatically when you auto-inject them
but anything else should be manually require-d anyway
Nick Sutterer
@apotonick
Aug 16 2016 08:07
the auto-inject mechanism has loader code?
Tim Riley
@timriley
Aug 16 2016 08:10
It calls Container.load_component for each of the specified dependencies: https://github.com/dry-rb/dry-system/blob/master/lib/dry/system/injector.rb#L63
But this is mostly about lazy loading during cases when you don’t want to fully boot/finalize a container (like during tests or when you only want to partially use one of your systems)
Nick Sutterer
@apotonick
Aug 16 2016 08:12
and where does the actual non-lazy loading happen?
Tim Riley
@timriley
Aug 16 2016 08:12
In a production-like environment, you’d finalize your container, which loads everything upfront via mechanisms like the auto-registration
In the case of the injector, it happens when e.g. include MyApp::Import[“foo”, “bar”] is evaluated
Nick Sutterer
@apotonick
Aug 16 2016 08:13
ok, one step back: i have x files with dependencies, e.g. file a needs file b. how would i start? chugg them all in a container?
how would the "container" find out the dependencies and what to load first, @timriley ?
Tim Riley
@timriley
Aug 16 2016 08:15
via the auto-injection
set up your container to auto-register a path
put <path>/foo.rb and <path>/bar.rb in it
then in foo.rb:
class Foo
  include MyImport[“bar”]

  def call(input)
    # bar is here and ready to work. it’s an instance of `Bar`
    bar.(input)
  end
end
MyImport = MyContainer.injector would have to be somehere too
You could probably build up a few things from there to get a feel for how they fit together
Nick Sutterer
@apotonick
Aug 16 2016 08:18
so i have to use include ... to "activate" the loading?
Tim Riley
@timriley
Aug 16 2016 08:19
if the container is not previously finalised and you want the other component to be automatically loaded for you, yeah
something has to trigger it :)
Luca Guidi
@jodosha
Aug 16 2016 08:20
OMG dry-system :heart:
Tim Riley
@timriley
Aug 16 2016 08:20
of course, depending on what you want to build, you may not need any of this ¯_(ツ)_/¯
@jodosha it really levelled up! :)
Luca Guidi
@jodosha
Aug 16 2016 08:20
:D
(I'm a bit lagged with news because of vacation / bare min time spent online ;) )
Nick Sutterer
@apotonick
Aug 16 2016 08:22
@timriley i am always keen to use as much existing stuff from you guys ;) so.. the idea is to include via the importing mechanism, which will load and then auto-inject the dependency, correct?
and by using include in the class, the dependencies are "resolved", it's basically like calling require on top of the class file... is that right?
Piotr Solnica
@solnic
Aug 16 2016 08:25
Yes
Nick Sutterer
@apotonick
Aug 16 2016 08:25
i understand that the auto-inject is meant for smaller pieces, but how do you handle bigger systems, e.g. let's say i don't need auto-injection for now when loading the operations
Piotr Solnica
@solnic
Aug 16 2016 08:27
It's based on DI so if you don't use DI it probably makes very little sense to use it, I think
Nick Sutterer
@apotonick
Aug 16 2016 08:28
ok, how does your DI idea apply to bigger components, e.g. an operation? who keeps the operation instance?
the controller? the app?
or am i misunderstanding the wiring here?
e.g. in rails, when the controller is instantiated, it could auto-inject the operation(s) and then in turn the operation could auto-inject necessary stakeholder objects such as contract and model. is that how it's supposed to work?
i understand the low-level but trying to apply it to a rails/hanami environment
Piotr Solnica
@solnic
Aug 16 2016 08:31
deps are injected from the container, so things must live in the container
we use auto-inject to do so, and auto-inject is configured with a specific container
Nick Sutterer
@apotonick
Aug 16 2016 08:35
ok, i remember the container being the reference book for all objects in the system, of any size, like contracts, operations, or functions like "persist user"
so i'd register all the TRB objects in the container, and then, when resolving the operation from the container, everything needed will auto-load? because that's what i want, and i want to use dry, of course
how would the container know where the operation files live, though?
Piotr Solnica
@solnic
Aug 16 2016 08:37
paths are configurable but we have a constraint 1 class == 1 file
this may go away soon, we’ll see
Nick Sutterer
@apotonick
Aug 16 2016 08:40
well that'll work since we tend to do the same
could i also use the container's resolving to load operation, contract, etc. without using auto-injection? because we don't have everything injectable yet
Nick Sutterer
@apotonick
Aug 16 2016 08:46
i guess the only way now is to play with it in a real environment, but i might have to ask for help
Piotr Solnica
@solnic
Aug 16 2016 09:06
@apotonick of course, auto-inject is not complex at all, it delegates heavy work to the container
so you just do Container.load_component(“foo/bar”) and you’re done
”foo.bar” will work too since we encounter for both file paths and object identifiers
Nick Sutterer
@apotonick
Aug 16 2016 09:07
yeah, i was thinking about the load_component for now, thanks @solnic <3
Vladimir Dralo
@vladra
Aug 16 2016 09:11
dry-system doesn't support auto loading modules out of the box. This is intentional behaviour?
Piotr Solnica
@solnic
Aug 16 2016 09:11
examples/standalone (master«) % be irb
irb(main):001:0> require './system/container'
=> true
irb(main):002:0> App.load_component('user_repo')
=> App
irb(main):003:0> UserRepo
=> UserRepo
@apotonick ^^
@vladra yes it is
the container is your entry point for deps, not constants
@apotonick we could actually make load_component return a component object (as in System::Component) and you can use it to instantiate your object, we support custom object loaders so you can tweak default behavior (which is just calling .new)
@apotonick when it comes to file loading there are some nice conveniences like glob requires ie App.require(‘operations/**/*.rb’)
and here’s a lowerish level stuff:
irb(main):003:0> App.load_component('user_repo')
=> App
irb(main):004:0> App.component('user_repo').instance
=> #<UserRepo:0x007fa9919858b8 @db=#<Sequel::SQLite::Database: “sqlite::memory”>>
and a component is just a data struct:
irb(main):005:0> App.component('user_repo')
=> #<Dry::System::Component identifier=“user_repo” path="user_repo">
Piotr Solnica
@solnic
Aug 16 2016 09:16
and it’s got a loader:
irb(main):006:0> App.component('user_repo').loader
=> #<Dry::System::Loader:0x007fa9909b85e8 @path=“user_repo”>
and loader knows how to figure out the constant:
Vladimir Dralo
@vladra
Aug 16 2016 09:17
@solnic and if for example I have some shared behaviour that is used in multiple repositories for example? It is still not correct way of using loader?
Piotr Solnica
@solnic
Aug 16 2016 09:17
irb(main):007:0> App.component('user_repo').loader.constant
=> UserRepo
@vladra just use require in your files
you could add auto-loading easily yourself if that’s what you want, personally I prefer explicit requires because when I see a long list of requires I also hear alarm bells :)
Nick Sutterer
@apotonick
Aug 16 2016 09:20
@solnic so basically i can use the loader stuff instead of my own, would highly prefer that
Vladimir Dralo
@vladra
Aug 16 2016 09:20
@solnic yeah, I've already added loader to support modules loading, just was wondering if it is a good practice. thanks
Piotr Solnica
@solnic
Aug 16 2016 09:21
@vladra hah awesome :) it is a matter of a personal preference really. I actually don’t remember if auto-loading is still a recommended practice, there use to be some issues with it with thread-safety, to a point it was considered this api should be removed from Ruby (IIRC they did manage to make it threadsafe eventually)
Nick Sutterer
@apotonick
Aug 16 2016 09:22
hang on @solnic what is App.require ?
a normal require with a load path?
Piotr Solnica
@solnic
Aug 16 2016 09:22
just Kernel.require but container-specific so it uses configured load paths and supports globing as a bonus
Nick Sutterer
@apotonick
Aug 16 2016 09:23
ok. however, how would i "configure" that a file update.rb is loaded after create.rb ?
Piotr Solnica
@solnic
Aug 16 2016 09:25
create.rb would have require ‘update’? :)
it’s really nice when files can be required in isolation
and it’s only a matter of having load-paths setup correctly
Nick Sutterer
@apotonick
Aug 16 2016 09:26
yeah, i'm all in for explicit requires,i hear you, but we're in a transition from the rails-does-everything to a fine-granular encapsulated design atm
Nick Sutterer
@apotonick
Aug 16 2016 09:32
@solnic is one App meant as one loader with one load path?
Vladimir Dralo
@vladra
Aug 16 2016 09:32
@solnic good to know :smile: https://bugs.ruby-lang.org/issues/5653
Nick Sutterer
@apotonick
Aug 16 2016 09:32
so, in case of rails engines, would i use a separate App instance for every gem?
@vladra i was talking to matz and he said he wants autoloading to be removed as it's dangerous and buggy sometimes
Vladimir Dralo
@vladra
Aug 16 2016 09:34
@apotonick I see, thanks
Nick Sutterer
@apotonick
Aug 16 2016 09:35
@solnic one App == one load path?
Piotr Solnica
@solnic
Aug 16 2016 09:36
nope, you can set multple load paths via Container.load_path!(*paths)
and if your objects implement .new in a way that is sufficient to call it w/o args, then you can auto-register them with default loader
Piotr Solnica
@solnic
Aug 16 2016 09:45
@apotonick feel free to report a dry-system issue and outline your trb requirements and we can see if it’s a good fit or not
Nick Sutterer
@apotonick
Aug 16 2016 09:47
it's not necessarily an issue, it's more like we're coming from two different places but want to reach the same destination ;)
i can't simply switch to auto-injection everywhere, even though i'd love to. BTW, how do you guys do inheritance? is that something that's frowned upon in dry?
inheritance needs explicit requires, doesn't it?
Nikita Shilnikov
@flash-gordon
Aug 16 2016 09:49
@apotonick it does, at least I use it this way
Nick Sutterer
@apotonick
Aug 16 2016 09:51
@flash-gordon you require dependencies for inheritance manually (as it should have been done ever since)?
Nikita Shilnikov
@flash-gordon
Aug 16 2016 09:51
@apotonick yes, like require_relative 'operation' or something like that
Nick Sutterer
@apotonick
Aug 16 2016 09:52
ok thanks :)
Nick Sutterer
@apotonick
Aug 16 2016 10:05
@solnic what if we had a container that was being "filled" by using trailblazer-loader? how would we say "this file is in /tmp/a and that file in /tmp/b?"
Nick Sutterer
@apotonick
Aug 16 2016 10:21
@solnic is the idea of the application container that it's populated/configured manually by the developer?
Piotr Solnica
@solnic
Aug 16 2016 10:27
it can be populated either automatically or manually, it depends on the use case
ie booting complex components uses manual registration
but even that could be automated if needed
container is no magic, it just stores stuff in a thread-safe hash :)
and dry-system’s container has additional APIs for loading files and configuring load-paths + auto-registration
everything is tweakable though, so ie config.auto_registrar can be set to a custom class that will handle auto-registration
you can easily override it
same with config.loader
my hunch is that we should be able to adjust behavior easily to load trb components
Nick Sutterer
@apotonick
Aug 16 2016 10:29
yeah same here, which is why i keep asking shit haha
until we have everything auto-injected, we might have to "work around" a bit
Piotr Solnica
@solnic
Aug 16 2016 10:30
auto-injection is an optional part of dry-system, it’s not a requirement
Nick Sutterer
@apotonick
Aug 16 2016 10:30
presently, we simply load all the smaller objects, e.g. contracts and representers, and then load the operations, per "concept". i would love to equip a container automatically and then use your loader
yeah but i want to use compositions more explicitly in TRB
but then, we must be able to say something like "load contract A::C before operation A"
trailblazer-loader currently simply compiles that list from a simple heuristic and then we require all files
Piotr Solnica
@solnic
Aug 16 2016 10:32
if A::C is a dependency of A then why not just put a require “a/c” in a.rb?
Nick Sutterer
@apotonick
Aug 16 2016 10:33
haha, and that's where the "transition" argument comes up, again
Piotr Solnica
@solnic
Aug 16 2016 10:33
well, you can set up auto-load for A::C :)
Nick Sutterer
@apotonick
Aug 16 2016 10:33
ruby's autoload?
Piotr Solnica
@solnic
Aug 16 2016 10:33
yes
Nick Sutterer
@apotonick
Aug 16 2016 10:33
slap
Piotr Solnica
@solnic
Aug 16 2016 10:33
:laughing:
Nick Sutterer
@apotonick
Aug 16 2016 10:33
ass
haha
no, seriously... i like the container idea, i like the loader idea, i like the auto-inject idea, but currently, we can't change everything at once, so we need this ordered loading

if we had auto-inject, an operation would look something along the following lines?

class A < TRB::Operation
  include Container[:a.contract]
  include Container[:a.representer]

right?

this would also save us from the explicit require... correct?
Piotr Solnica
@solnic
Aug 16 2016 10:58
@apotonick if you don’t specify what a given file needs, then there’s no way to resolve its deps, unless you want to use some conventions like file/dir structure representing dep hierarchy
Nick Sutterer
@apotonick
Aug 16 2016 10:59
@solnic ok, let's assume the container did know that somehow. the operation as seen above is "almost" correct, right? when instantiated, it would auto-inject the contract and representer?
Piotr Solnica
@solnic
Aug 16 2016 11:03
yep because that include specifes what this class needs
Nick Sutterer
@apotonick
Aug 16 2016 11:05
cool. i think i understand it now
Tim Riley
@timriley
Aug 16 2016 11:06
are those include lines are just kind of pseudo-code? because they don’t really make sense to me...
System::Container.[] resolves and returns an object from the container, and unless it’s a module subclass, I don’t see why you’d be including it?
Piotr Solnica
@solnic
Aug 16 2016 11:07
right, this would have to be the import mixin provided by the container
I assumed it was pseudo code
Nick Sutterer
@apotonick
Aug 16 2016 11:10
yeah, i didn't really know the right syntax
timriley @timriley wonders whether we should add some kind of #null? predicate to dry-view parts...
Tim Riley
@timriley
Aug 16 2016 11:16
there are some circumstances where doing something like this would actually be helpful:
- if my_thing.null?
  / `my_thing` is a nil value, wrapped in a NullPart
  == some_partial
  == another_partial
- else
  / `my_thing` is a real non-nil value in this case
  == special_partial
  == another_partial
i.e. when you want to break your view up into partials that all share the same view scope
and then branch slightly based on whether my_thing is nil or not
dan-klasson
@dan-klasson
Aug 16 2016 11:20
@timriley in a view? that's ugly imho. better to put that nil in in a cell method or helper method, then call that method from your view
Tim Riley
@timriley
Aug 16 2016 11:20
yeah, provide an actual null object
dan-klasson
@dan-klasson
Aug 16 2016 11:20
still
Tim Riley
@timriley
Aug 16 2016 11:20
I don’t really know what you mean by putting it in a cell method or helper method
dan-klasson
@dan-klasson
Aug 16 2016 11:21
well in TRB with cells that would be a perfect example of a cell "helper" method
what i am getting at is checking for nil values, whether using a null object or not, in a view, is ugly, in my opinion. that logic does not belong in the view layer
Tim Riley
@timriley
Aug 16 2016 11:23
Fair enough.
Tim Riley
@timriley
Aug 16 2016 11:38
I’m of the opinion that it’s OK to let a little purity go in view templates, especially if you’re working with a team where not everyone is writing ruby everyday (i.e. the kind of people who are great at front-end stuff and making your apps look great)
Piotr Solnica
@solnic
Aug 16 2016 11:38
yeah we need custom decorators for parts @timriley so that this logic can be hidden there
Tim Riley
@timriley
Aug 16 2016 11:39
custom decorators, you say?
Piotr Solnica
@solnic
Aug 16 2016 11:39
that’s a fair point too
Tim Riley
@timriley
Aug 16 2016 11:39
Yeah, otherwise you never get anything built
Piotr Solnica
@solnic
Aug 16 2016 11:39
my brain is sort-of disconnected from dry-view these days as I didn’t use it since March but IIRC that was my idea from the beginning, to be able to decorate parts with custom methods
Tim Riley
@timriley
Aug 16 2016 11:40
that might help a lot...
Piotr Solnica
@solnic
Aug 16 2016 11:40
like cells, but withouth html-rendering helpers, we want pure template rendering exclusively
Tim Riley
@timriley
Aug 16 2016 11:40
if you find a few minutes to remember the ideas you had, I would be happy to look at implementing
Piotr Solnica
@solnic
Aug 16 2016 11:40
template + data
dan-klasson
@dan-klasson
Aug 16 2016 11:41
@timriley Yeah it's all about whether code quality matters or not. It will take time to teach people that for sure. But then again, where does one draw the line? We could all be following the the Rails way using the same logic ;)
Tim Riley
@timriley
Aug 16 2016 11:42
I draw the line at the view templates :)
I take your point, though.
Piotr Solnica
@solnic
Aug 16 2016 11:42
@timriley couldn’t we just nest view objects?
ie one view object uses other view objects?
and pass them as locals?
Tim Riley
@timriley
Aug 16 2016 11:43
what’s this to achieve specifically, sorry?
Piotr Solnica
@solnic
Aug 16 2016 11:44
views are your objects, so you can encapsulate conditional rendering there, no?
brain, disconnected, probably you should just ignore everything I just wrote O_o
Tim Riley
@timriley
Aug 16 2016 11:45
Yeah, nested view components and everything, I get that, like React, but I don’t see how that meshes with dry-view’s model atm...
dan-klasson
@dan-klasson
Aug 16 2016 11:46
@solnic Are we talking views or view objects?
Piotr Solnica
@solnic
Aug 16 2016 11:49
@timriley ok :D
dan-klasson
@dan-klasson
Aug 16 2016 12:22
@timriley In my experience I've noticed, any layer can become cumbersome. I've seen horrible views that are just copy and paste from others, that could easily have been inherited as components. Which is fine, until you want to change the design. Then it's a nightmare. Not saying null objects has anything to do with that, but when you start cutting corners, that's how it usually ends up.
Piotr Solnica
@solnic
Aug 16 2016 12:30
here’s a nice example why rails is a fundamentaly broken framework: https://groups.google.com/forum/#!topic/ruby-security-ann/WccgKSKiPZA
Nick Sutterer
@apotonick
Aug 16 2016 13:11
@solnic @timriley i would highly recommend taking a stab at cells. you don't have to use any html rendering helpers, they are not even there outside rails
the template is the cell object, the data either a decorated object/model or let the cell decorate it.
the cell gives you super fast rendering, and view inheritance, etc. we have some massively cool changes in cells 5.0 coming
Andy Holland
@AMHOL
Aug 16 2016 16:06
@apotonick been meaning to look into cells and roar for a while now, both look really nice, hopefully I'll get some time soon
Nick Sutterer
@apotonick
Aug 16 2016 16:08
@AMHOL cells, getting started: trailblazer.to/gems/cells/getting-started.html it will take up 5 mins of your time :*
Andy Holland
@AMHOL
Aug 16 2016 16:08
TY :)
Andy Holland
@AMHOL
Aug 16 2016 16:16
@apotonick I take it you're talking about not duplicating efforts with dry-view/cells?
Vladimir Dralo
@vladra
Aug 16 2016 16:43

got error using dry-system with Hanami. Can't find solution, any tips ?

ArgumentError: wrong number of arguments (given 1, expected 0)
    /usr/local/lib/ruby/gems/2.3.0/gems/dry-auto_inject-0.4.1/lib/dry/auto_inject/strategies/kwargs.rb:12:in `new'

this is result of using auto inject in Hanami View

Andy Holland
@AMHOL
Aug 16 2016 16:47
Can you post an example of how you're using it @vladra ?
Vladimir Dralo
@vladra
Aug 16 2016 16:52
Import = App.injector
module Web::Views::Users
    class Create
        include Web::View
        include Import['repositories.users']
    end
end
something like this
to mention, I have this problem only where include Web::View is present. In other places everything works fine
Andy Holland
@AMHOL
Aug 16 2016 17:00
@vladra try Import = App.injector.args
Vladimir Dralo
@vladra
Aug 16 2016 17:17
@AMHOL great, this solved my issue, thanks! :+1:
Piotr Solnica
@solnic
Aug 16 2016 17:27
we should catch and wrap exceptions in this kind of situations and provide some nice feedback
catch-and-re-raise*
Nick Sutterer
@apotonick
Aug 16 2016 18:56
@AMHOL yeah exactly, instead of rewriting all the things we've worked out in cells in 10 years, rather focus on all the other cool things you guys create
and tell us what you need ;)
Piotr Solnica
@solnic
Aug 16 2016 18:58
@apotonick @AMHOL @timriley would be nice to look at dry-view and cells together one day and see if we’re really talking about the same thing (at the very abstract level)
Nick Sutterer
@apotonick
Aug 16 2016 18:59
we are - i don't know what else you'd mean by data and template ?!?!
Andy Holland
@AMHOL
Aug 16 2016 18:59
:+1:
Nick Sutterer
@apotonick
Aug 16 2016 18:59
cells is so super simple that i am highly confident it will suit your view of a view (no pun intended)
Andy Holland
@AMHOL
Aug 16 2016 19:00
:laughing:
Piotr Solnica
@solnic
Aug 16 2016 19:00
well, it depends on the point of view
Nick Sutterer
@apotonick
Aug 16 2016 19:01
haha
Piotr Solnica
@solnic
Aug 16 2016 19:01
:)
Nick Sutterer
@apotonick
Aug 16 2016 19:02
cell is: Whatever::Cell.new(data_object, additional: args).()
which could be even minified to Whatever::Cell.(...)
in other words: a cell is a function to render a template
the only difference is that this "function" is a functional object that can decorate the data object and provide additional "helpers", which are instance methods on the cell
Piotr Solnica
@solnic
Aug 16 2016 19:06
and view locals are what?
Nick Sutterer
@apotonick
Aug 16 2016 19:07
view locals are instance methods on the cell instance
everything in the view template is called as an instance method on the cell. this is super super nice, i can't stress how helpful this is to keep your views clean
without having global helper shit going on
Krzysztof Wawer
@wafcio
Aug 16 2016 21:15
I have generated dry-web-roda sample app and inside Gemfile I found that ROM gems are fetching from Github instead of released version (rubygems). Is there any reason why they are fetching from Github ?
I think this skeleton is little old, there is still shotgun, but rack isn’t locked for version below 2.0. Maybe shotgun should be changed to notgun.
Tim Riley
@timriley
Aug 16 2016 21:27
@wafcio yeah, I need to make an update release, I will aim for later this week!
Happy to look at a PR if you have time in the meantime :)
Krzysztof Wawer
@wafcio
Aug 16 2016 21:28
sure I can create PR for it
I wasn’t sure in which way you want to follow.
Tim Riley
@timriley
Aug 16 2016 21:29
@apotonick one thing we need from view classes is for them to be DI-friendly. That is, accept dependencies in the initializer and then "local" data in #call
Tim Riley
@timriley
Aug 16 2016 21:39
@wafcio happy to have help, most definitely :)
Piotr Solnica
@solnic
Aug 16 2016 21:41
@apotonick @timriley right, seems like the biggest diff is that dry-view’s are not stateful wrt locals data, they only accept deps in the constructor that are used to fetch data
Piotr Solnica
@solnic
Aug 16 2016 23:28
I built a railtie for dry-system but it turned out to be an empty class :laughing: https://github.com/dry-rb/dry-system-rails