-
Notifications
You must be signed in to change notification settings - Fork 14
while_loading / on_error redo #251
Comments
i still dont like it |
Sorry to be wishy-washy, but I honestly don't mind either way. |
I also think they seem similar and I'm not too bothered. They kinda seem like events, like JS onload and such. Is there also an while_loading inside the component as a hook? I see 2 things you might want to do. Using someone else's component you do your own stuff while loading using the events above. But if you're making a component then within that component you might want to show a placeholder while the data is loading. Something like: class Foo < Hyperloop::Component
# I guess this is used instead of render until render is done
while_loading do
DIV { "loading foos" }
end
render(DIV) do
::Foo.all.each do |foo|
DIV { foo.name }
end
end
end And a 3rd option, you may wish to display the load indicator inline: class Foo < Hyperloop::Component
render(DIV) do
unless ReactiveRecord::WhileLoading.quiet?
DIV(class: "load-indicator") { "Loading..." }
end
::Foo.all.each do |foo|
DIV { foo.name }
end
end
end |
second option, yeah can be done, or also perhaps: render(DIV) do
end
.on(:loading) do
...
end the callbacks are nice too, though render do
Try do
...
end
.on(:loading) do
...
end
end Regarding the third option... I don't quite understand it... if ...quiet?
normal code
else
code to show while loading?
end that is okay but Try / while_loading will give you a lot more power. In particular it will only react to the code within its block, while The idea is deep down I am getting data on say a user in a list... that list item can have its own spinner and the whole page does not have to effected (if that is your desired behavior) |
currently
.while_loading
is attached to a component like this:Now that React 16 (and Hyperloop 1.0) have error handling it would be nice to extend this syntax like this:
but in order for this to work there is a vast amount of trickery inside of Hyper-React and Hyper-Mesh.
Everything can be greatly simplified if we create a wrapper Psuedo component, and just reuse the existing event handler mechanism:
I am proposing using the .on(...) syntax for a couple of reasons:
Note that the current 1.0.0 (edge) error handling call back (as defined by @janbiedermann ) would remain and can still be used, and would in fact be the basis for implementing the above.
The text was updated successfully, but these errors were encountered: