-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use trailblazer-option over declarative-option and upgrade declarative-builder #492
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
require "trailblazer/option" | ||
require "uber/callable" | ||
|
||
# DISCUSS: Should we move this to trb-option instead ? | ||
# This is identical to `Representable::Option`. | ||
module Cell | ||
# Extend `Trailblazer::Option` to support static values as callables too. | ||
class Option < ::Trailblazer::Option | ||
def self.callable?(value) | ||
[Proc, Symbol, Uber::Callable].any?{ |kind| value.is_a?(kind) } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure about this change. We quite frequently pass symbols as cell options, is this going to to try and evaluate them as a method name? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @samstickland This behaviour is same as the previous There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @yogeshjain999 We do have static values covered in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh really ? I thought those are covered in declarative-option directly. |
||
end | ||
|
||
def self.build(value) | ||
return ->(*) { value } unless callable?(value) # Wrap static `value` into a proc. | ||
super | ||
end | ||
end | ||
|
||
class Options < Hash | ||
# Evaluates every element and returns a hash. Accepts arbitrary arguments. | ||
def call(*args, **options, &block) | ||
Hash[ collect { |k,v| [k,v.(*args, **options, &block) ] } ] | ||
end | ||
end | ||
|
||
def self.Option(value) | ||
::Cell::Option.build(value) | ||
end | ||
|
||
def self.Options(options) | ||
Options.new.tap do |hsh| | ||
options.each { |k,v| hsh[k] = Option(v) } | ||
end | ||
end | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@apotonick This is identical to Representable::Option.
Should we move
Cell::Option
andCell::Options
in trb-option instead ?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, do we have use on a generic level?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, kind of.
Cell::Options
isn't generic. We can keep it here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The question is, do we have the static requirement anywhere else (e.g. Reform)? If yes, we can extract it. On the other hand, we can always do that later. 🥱
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, we've the static requirement in reform, disposable and representer. Currently, it is done in representer itself and it's being used in other 2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand, supporting
Callable
objects between these 2 types of gems (representable, reform, cells etc and trb-activity, DSL etc) is little different i.e.Uber::Callable
for identifying callable object.So other way is we should not mix these 2 types in trb-option but keep separate. If it's ok, then we can keep
Cell::Option
here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uber::Callable
, that one we should dump ASAP. Isn't it better if we always treat an objectcall
able, anyway?Option
s, right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm yeah. The problem with treating every object callable is we can't distinguish between them and static options (some static options also includes modules, classes etc), apart from
call
method.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahhh, ok right, so that was why I initially introduced
Uber::Callable
, damn! Hm... how could we do that in the future?Ok, in that case, we won't move that behavior to TRB, for now. 🍰
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct (i.e. distinction between static and callable objects isn't needed in TRB). So we can merge this PR.
Uber::Callable
is a nice alternative to mark callables forcells
andrepresentable friends
for now.In future versions, maybe we can have restrictions on static options (or ways to avoid them) ?