Create a lazy signal that employs an Effect

[bbarker]

I'd like to have something like a signal that reads the current date:

dateTimeWidg :: Widget HTML DateTime
dateTimeWidg = liftEffect nowDateTime

dateTimeSig :: Signal HTML DateTime
dateTimeSig = sig initDate
  where
    sig dt = step dt do
      newDt <- dateTimeWidg
      pure $ sig newDt

The widget seems fine, however, the signal creates an infinite (eagerly evaluated) loop, since dateTimWidg returns immediately.

Ideally, there would be a way to have dateTimeSig only queried when other signals at the same level fire. The particular goal here is that I have user's inputting data to records, but this particular field of the record should be automatically timestamped by the app.

[bbarker]

I guess I would add that I think this would not be an issue if I could call liftEffect from Signal directly, but its type doesn't allow for that, as far as I can tell.

[ajnsit]

A signal must always have a value, even just after construction. With a liftEffect :: Effect a -> Signal a, it's not possible to have an a before executing the effect, hence there's no way to make a signal with just an effect.

It is however possible to have functions -

-- For pure side effects
execEffect :: Effect Unit -> Signal Unit
execEffect e = step unit do
  a <- liftEffect e
  pure (step unit empty)

-- Or when you want the return value
runEffect :: forall a. Effect a -> Signal (Maybe a)
runEffect e = step Nothing do
  a <- liftEffect e
  pure (step (Just a) empty)

-- Or with a supplied initial value instead of using a Maybe
runEffectWithInit :: forall a. a -> Effect a -> Signal a
runEffectWithInit i e = step i do
  a <- liftEffect e
  pure (step a empty)

For dateTimeSig, the runEffectWithInit function should suffice. The date will get updated everytime the signal reflows from upstream. This allows you to control how often you want to poll for the current date.

[bbarker]

@ajnsit Thanks, this does look like what I need. But a question: at first I thought empty was mempty, but that seems incorrect - what is it?

[ajnsit]

empty is similar to mempty. It's the identity for <|> (alt) just like mempty is the identity for <> (append). empty is defined in the Plus class.

Basically -
Plus:empty:Alt:alt = Monoid:mempty:Semigroup:append

[bbarker]

Ah, I see! I'd been using mempty for Concur in the past but now realize that was for values of type HTML, rather than for type families like Widget.

I'm getting the following type error with the code at the moment:

[1/1 KindsDoNotUnify] src/Metajelo/FormUtil.purs:405:49

  405  runEffectWithInit :: forall a. a -> Effect a -> Signal a
                                                       ^^^^^^

  Could not match kind

    Type

  with kind

    Type -> Type

  while checking the kind of a -> Effect a -> Signal a
  in value declaration runEffectWithInit

The new type signature I'm using is:

runEffectWithInit :: forall a v. MonadEffect v => a -> Effect a -> Signal v a

But I get a similar error:

[1/1 KindsDoNotUnify] src/Metajelo/FormUtil.purs:404:68

  404  runEffectWithInit :: forall a v. MonadEffect v => a -> Effect a -> Signal v a
                                                                          ^^^^^^

  Could not match kind

    Type

  with kind

    Type -> Type

  while checking the kind of MonadEffect v => a -> Effect a -> Signal v a
  in value declaration runEffectWithInit

[bbarker]

It does work with the concrete type HTML used in place of v, pointing to the issue with kinds, though not sure how to address it yet.

[bbarker]

To qualify my above comment, when I said it works, it does compile, but the issue of the app hanging still seems to occur, with an out of memory error reported on the browser's console.

[ajnsit]

runEffectWithInit :: forall a v. MonadEffect v => a -> Effect a -> Signal v a

Ah you don't need the MonadEffect here. v here is the view and of kind *, but a Monad or MonadEffect needs to take a type parameter and so needs to be of kind * -> *

In the code I posted, I had omitted the view argument to Signal so you only need to add that back. You will likely need a Monoid constraint though since most functions for Signals require it. i.e. runEffectWithInit :: forall a v. Monoid v => a -> Effect a -> Signal v a

To qualify my above comment, when I said it works, it does compile, but the issue of the app hanging still seems to occur, with an out of memory error reported on the browser's console.

That's strange, it seems to work for me. Can you show me the code?

I also realised that I already have something similar called fireOnce in Concur.Core.FRP -

fireOnce :: forall v a. Monoid v => Widget v a -> Signal v (Maybe a)

Which can be used with liftEffect to get the same functionality as runEffect. For example, this works for me and shows the current date on the page -

import Effect.Now (now)
showCurrentInstant = dyn do
      name <- justWait
              "UNKNOWN"
              (fireOnce do liftEffect do map show now)
              pure
      display $ D.text name

[bbarker]

@ajnsit Ah, I see my error with regard to MonadEffect, should have thought about that more carefully.

I added updated code in the stampModifiedTime branch; see diff. This causes the default user experience found in the master branch to break as described.

By the way, this might be a good time to mention that this app is getting very close to being useful. I still need to add debouncing to prevent frequent DOM updates, and possibly remove formless as mixing it with continuously updating signals doesn't seem to have much benefit, and does add a few idiosyncrasies with regard to user experience.
In particular, I found the way that I've been using purescript-option in UI.purs rather appealing for using Concur to build modular components that update a hierarchy of records; Option is serving as a thin library to support model and view-model. Would be great to have your opinion on this and ways it could be improved, maybe discussed in another thread. I'm currently using a fork of purescript-option, primarily because sometimes I can't wait for things to be merged :-).

[ajnsit]

@bbarker I replied to your issue about debouncing. Closing this. Please feel free to reopen if necessary.

[bbarker]

@ajnsit This was actually unrelated to debounce, except that debounce might be used as a way to hack around the issue. My above comment states, perhaps not very directly, that this issue is not yet resolved, and provides a branch that elicits the undesirable behavior of the apparent infinite loop.

[ajnsit]

Ah I see, reopening the issue.

[ajnsit]

@bbarker Is it possible to have a small independent code snippet that reproduces the problem?