-
-
Notifications
You must be signed in to change notification settings - Fork 12
Description
A fix is possible in the main Halogen code, but the issue only affects Hooks users, so I wouldn't consider it a regular Halogen issue.
The help docs for emit are a bit too specific, where a is assumed to be an "action".
emit :: forall m a. Emitter m a -> a -> m UnitEmits an action via the emitter. For example:
data Action = Notify String
myEventSource = EventSource.affEventSource \emitter -> do
Aff.delay (Milliseconds 1000.0)
EventSource.emit emitter (Notify "hello")
pure memptyThis assumption is fine for regular Halogen, and I can't think of a situation where you'd want to use anything besides a component's Action type, but this is misleading for usage with Hooks because a needs to be HookM m Unit.
I don't know what the best strategy is for improving Halogen docs that require a different interpretation for Hooks. Making the Halogen docs too generic may be more confusing for beginners. Perhaps more Hooks examples would help. There's nothing available yet demonstrating effectEventSource and affEventSource.
For context here's a partial Ace example with effectEventSource. Considering adding something like this to the cookbook.
content /\ setContent <- useStateFn HK.put "some content"
document /\ setDocument <- useStateFn HK.put (Nothing :: Maybe Document)
HK.useLifecycleEffect do
doc <-
liftEffect do
-- Create an editor
editor <- Ace.edit "editor" Ace.ace
session <- Editor.getSession editor
docInner <- Session.getDocument session
_ <- Document.setValue content docInner
_ <- Editor.navigateFileStart editor
pure docInner
-- Ignoring subscription ID
_ <-
HK.subscribe do
ES.effectEventSource \emitter -> do
-- Ignoring DocumentEvent
Document.onChange doc \_ -> do
str <- Document.getValue doc
ES.emit emitter $ setContent str
-- No finalizer
pure mempty
setDocument $ Just doc
pure Nothing