consistent name/semantics/syntax for all handlers

[catmando]

there are three "modifiers" when a component is mounted:
on(...)
while_loading
after_error (proposed, but will probably be added in 1.0)

A proposal is to make these consistent like this:
on(...) where there are two (currently) special events: :loading, and :error.

class MyComponent < Hyperloop::Component
  render do
    DIV do
      ...
    end
    .on(:click) { alert('you clicked me!') }
    .on(:loading) { IMG(src: 'spinner.png') }
    .on(:error) { IMG(src: 'sad-face.png') }
  end
end

part two would be to add a new on callback which would apply these handlers to the component as a whole... so the above could be rewritten as:

class MyComponent < Hyperloop::Component
  render do
    DIV do
      ...
    end
  end
  on(:click) { alert('you clicked me!') }
  on(:loading) { IMG(src: 'spinner.png') }
  on(:error) { IMG(src: 'sad-face.png') }
end

or even

class MyComponent < Hyperloop::Component
  render(DIV) do
      ...
  end
  on(:click) { alert('you clicked me!') }
  on(:loading) { IMG(src: 'spinner.png') }
  on(:error) { IMG(src: 'sad-face.png') }
end

regardless of the specific syntax, we should allow these modifiers consistently to be used either inside a components render method using the .xxx notation, or to be applied to the whole component using a callback.

We need this because we have the render(ComponentName) do ... end syntax which precludes using the .xxx notation.

[catmando]

FYI... even though while_loading is a hyper-model feature, i think the basic mechanism belongs here.
In fact I would say that implementation wise we would add something like this to Hyperloop::Component

Hyperloop::Component.register_render_action(name, block)

The name is the name (like error and loading) and the block should generate an element (just like render) which will replace the normally rendered element.

You can then someplace else do a Hyperloop::Component.throw(name, *args) where the args will be passed on to the corresponding block.

maybe... might not work nicely for error, I don't know... but seems like we can reuse most of the mechanism used by error, and extend it so its more of a general catch/throw mechanism

[janbiedermann]

For clarification: after_error is currently implemented as a callback like before_mount or after_mount

on(:loading)currently is not a event but a condition/state, the resembling events would have to be:
on(:loading_started) and on(:loading_finished)
Thats also why i think the onsyntax can be misleading here, because you want to render something during the condition/state 'loading', not only when the loading starts or ends.
But these on(:loading_started) and on(:loading_finished) might be useful in addition.