before_action like filters for inertia_share

[skryukov]

This PR builds on the approach from #121 and aims to resolve the concerns raised in #115 (comment).

It introduces some complexity as we need to partially reimplement Rails callbacks to work with @ElMassimo's shared properties feature.

@bknoles, I'd like to get your opinion on this approach. Do you think it's worth it to continue refining this PR?

Supported options:

inertia_share normal_shared_prop: 1

inertia_share(normal_shared_prop: 1)

inertia_share do
  {conditionally_shared_show_prop: 1} if action_name == "show"
end

inertia_share only: :edit do
  {only_block_prop: 1}
end

inertia_share except: [:show, :index] do
  {except_block_prop: 1}
end

inertia_share if: -> { is_edit? } do
  {if_proc_prop: 1}
end

inertia_share unless: -> { !is_edit? } do
  {unless_proc_prop: 1}
end

inertia_share({only_prop: 1}, only: :edit)

inertia_share({if_prop: 1}, if: [:is_edit?, -> { true }])

inertia_share({unless_prop: 1}, unless: :not_edit?)

inertia_share({only_if_prop: 1}, only: :edit, if: -> { true })

inertia_share({except_if_prop: 1}, except: [:index, :show], if: -> { true })

Caveat:

inertia_share normal_shared_prop: 1, only: :edit
# => raises "You must not mix shared data and [:if, :unless, :only, :except] options, pass data as a hash or a block.
inertia_share(normal_shared_prop: 1, only: :edit)
# => raises "You must not mix shared data and [:if, :unless, :only, :except] options, pass data as a hash or a block.
inertia_share({normal_shared_prop: 1, only: :edit})
# => adds only: :edit as a prop
inertia_share({normal_shared_prop: 1, only: :edit}, only: :edit)
# => adds only: :edit as a prop only for :edit action

[bknoles]

I love the API. Especially the clear and helpful exceptions if you try write something that could lead to keyword collision.

Last night when I looked at this, I worried about this as well:

we need to partially reimplement Rails callbacks

I.e. would it be confusing for someone new if the API to kinda sorts resembles before_action, but actually does something different?

However, after thinking about it, I think keys like if/only/except/unless are generic enough that they don't "belong" to callbacks. The pattern here feels very much like a Rails pattern, rather than a Rails callbacks pattern.

I'm in favor of adding. I would use this in existing apps.

@BrandonShar can you strawman this? Are there any other potential downsides you can think of that we should consider?

[BrandonShar]

I like it! I think this is a nice "papercut" style improvement that feels very in line with existing expectations for rails users.

Just two minor comments I'd prefer be addressed before we merge.

[BrandonShar]

Thanks for the back and forth!