[elm-discuss] Structuring model and messages | Debouncing in a large app

[Simon]

First of all - 6 debouncing libraries! Would be great to see elm-package be
able to surface github stars directly (or some other means of identify the
most-likely-to-be-good library)

My question though is the following. The type signature of a debounce state
is DebounceState Msg. I.e. it needs the message type as that’s what it is
going to send back later.

But in a large app, I usually have the model in 1 file and import that into
my update/view files and it is in the latter that I define the type Msg.

I’m quickly going to get a singularity if I try to import my Msgs into my
model.

I’ve never separated out my Msgs before into a separate file but can see
some other benefits. But there will also be costs too.

So I was wondering

- what other experiences people had had with separating out Msgs
- whether there was an alternative to this to handle the issue at hand -
debouncing (all of the examples in the libraries are tiny single file ones
inevitably)

​

[j***@pivotal.io]

My comment is RE debouncing in particular. I too have been frustrated to
see so many debouncing libraries. The problem is that none of them are
great, because debouncing makes the most sense to solve as a managed
effect, rather than in user-space. And, effect packages can't be published
afaik. There are quite a few of this type out there on github. The one
that we use to good effect is
here: https://github.com/tracker-common/elm-debouncer/blob/be3bd02ccac6b71b0088c08359b3f45b5ae7c4dc/src/Debouncer.elm
(sorry for the outstanding PR). It provides an api very similar to
Task.attempt, but the task given to it will be debounced. There are
similar ones that deal with Msg instead of tasks
(https://github.com/unbounce/elm-debounce), but I like to keep my effects
in tasks as long as possible so I can chain/map them as needed before
sending them out.

Post by Simon
First of all - 6 debouncing libraries! Would be great to see elm-package
be able to surface github stars directly (or some other means of identify
the most-likely-to-be-good library)
My question though is the following. The type signature of a debounce
state is DebounceState Msg. I.e. it needs the message type as that’s what
it is going to send back later.
But in a large app, I usually have the model in 1 file and import that
into my update/view files and it is in the latter that I define the type
Msg.
I’m quickly going to get a singularity if I try to import my Msgs into my
model.
I’ve never separated out my Msgs before into a separate file but can see
some other benefits. But there will also be costs too.
So I was wondering
- what other experiences people had had with separating out Msgs
- whether there was an alternative to this to handle the issue at hand
- debouncing (all of the examples in the libraries are tiny single file
ones inevitably)
​

[Simon]

THANKS SO MUCH!!!!!

I don't know that whether its true that effects modules can't be published
on elm-package - this one at least has no native code which I know to be a
blocker.

But as we both noted, there are times when the TEA does not, and arguably
cannot, provide a good developer experience. It is such a shame that
effects modules are so frowned upon.

Post by j***@pivotal.io
My comment is RE debouncing in particular. I too have been frustrated to
see so many debouncing libraries. The problem is that none of them are
great, because debouncing makes the most sense to solve as a managed
effect, rather than in user-space. And, effect packages can't be published
afaik. There are quite a few of this type out there on github. The one
https://github.com/tracker-common/elm-debouncer/blob/be3bd02ccac6b71b0088c08359b3f45b5ae7c4dc/src/Debouncer.elm
(sorry for the outstanding PR). It provides an api very similar to
Task.attempt, but the task given to it will be debounced. There are
similar ones that deal with Msg instead of tasks (
https://github.com/unbounce/elm-debounce), but I like to keep my effects
in tasks as long as possible so I can chain/map them as needed before
sending them out.

Post by Simon
First of all - 6 debouncing libraries! Would be great to see elm-package
be able to surface github stars directly (or some other means of identify
the most-likely-to-be-good library)
My question though is the following. The type signature of a debounce
state is DebounceState Msg. I.e. it needs the message type as that’s
what it is going to send back later.
But in a large app, I usually have the model in 1 file and import that
into my update/view files and it is in the latter that I define the type
Msg.
I’m quickly going to get a singularity if I try to import my Msgs into
my model.
I’ve never separated out my Msgs before into a separate file but can see
some other benefits. But there will also be costs too.
So I was wondering
- what other experiences people had had with separating out Msgs
- whether there was an alternative to this to handle the issue at
hand - debouncing (all of the examples in the libraries are tiny single
file ones inevitably)
​

[Gusztáv Szikszai]

This is really good :+1

Post by j***@pivotal.io
My comment is RE debouncing in particular. I too have been frustrated to
see so many debouncing libraries. The problem is that none of them are
great, because debouncing makes the most sense to solve as a managed
effect, rather than in user-space. And, effect packages can't be published
afaik. There are quite a few of this type out there on github. The one
https://github.com/tracker-common/elm-debouncer/blob/be3bd02ccac6b71b0088c08359b3f45b5ae7c4dc/src/Debouncer.elm
(sorry for the outstanding PR). It provides an api very similar to
Task.attempt, but the task given to it will be debounced. There are
similar ones that deal with Msg instead of tasks (
https://github.com/unbounce/elm-debounce), but I like to keep my effects
in tasks as long as possible so I can chain/map them as needed before
sending them out.

Post by Simon
First of all - 6 debouncing libraries! Would be great to see elm-package
be able to surface github stars directly (or some other means of identify
the most-likely-to-be-good library)
My question though is the following. The type signature of a debounce
state is DebounceState Msg. I.e. it needs the message type as that’s
what it is going to send back later.
But in a large app, I usually have the model in 1 file and import that
into my update/view files and it is in the latter that I define the type
Msg.
I’m quickly going to get a singularity if I try to import my Msgs into
my model.
I’ve never separated out my Msgs before into a separate file but can see
some other benefits. But there will also be costs too.
So I was wondering
- what other experiences people had had with separating out Msgs
- whether there was an alternative to this to handle the issue at
hand - debouncing (all of the examples in the libraries are tiny single
file ones inevitably)
​

[Gusztáv Szikszai]

I've never though about using an effect manager for debouncing, it makes
much more sense. Thanks for sharing!

Post by Gusztáv Szikszai
This is really good :+1

Post by j***@pivotal.io
My comment is RE debouncing in particular. I too have been frustrated to
see so many debouncing libraries. The problem is that none of them are
great, because debouncing makes the most sense to solve as a managed
effect, rather than in user-space. And, effect packages can't be published
afaik. There are quite a few of this type out there on github. The one
https://github.com/tracker-common/elm-debouncer/blob/be3bd02ccac6b71b0088c08359b3f45b5ae7c4dc/src/Debouncer.elm
(sorry for the outstanding PR). It provides an api very similar to
Task.attempt, but the task given to it will be debounced. There are
similar ones that deal with Msg instead of tasks (
https://github.com/unbounce/elm-debounce), but I like to keep my effects
in tasks as long as possible so I can chain/map them as needed before
sending them out.

Post by Simon
First of all - 6 debouncing libraries! Would be great to see elm-package
be able to surface github stars directly (or some other means of identify
the most-likely-to-be-good library)
My question though is the following. The type signature of a debounce
state is DebounceState Msg. I.e. it needs the message type as that’s
what it is going to send back later.
But in a large app, I usually have the model in 1 file and import that
into my update/view files and it is in the latter that I define the type
Msg.
I’m quickly going to get a singularity if I try to import my Msgs into
my model.
I’ve never separated out my Msgs before into a separate file but can
see some other benefits. But there will also be costs too.
So I was wondering
- what other experiences people had had with separating out Msgs
- whether there was an alternative to this to handle the issue at
hand - debouncing (all of the examples in the libraries are tiny single
file ones inevitably)
​