Yes we spoke about how the idea of having "sections" within a page that
function as independent units. The idea of mini-apps seems to encompass the
approach of splitting out the app into Pages and page Sections. I don't
have time now but I'll try to put down a description of our app later on
to
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 need
https://codepen.io/anon/pen/gWrbxr
On Wednesday, 19 April 2017 14:16:08 UTC+1, Duane Johnson wrote:
>
>
> On Tue, Apr 18, 2017 at 7:20 AM, Jakub Hampl > wrote:
>
>> Think of the element akin to the element in HTML. Yes, fairly
>> often you will simply pass a string to it, but it needing lower
Richard,
What I'm saying is that *individual functions*, as opposed to *a group of
> functions and data structures* (model, view, update, msg, etc) is the
> right unit of composition.
I struggle to understand to see where is a difference. Html.program
constructor is record of functions as wel
I am trying to parse a recursive structure using
http://package.elm-lang.org/packages/elm-tools/parser/latest .
Here is an try: https://ellie-app.com/WwGfQGWRHfa1/9
For example, I'd like to parse something like this:
>> "ab"
>> "cd"
>> "ef"
>> "gh"
>> "ij"
>> "kl"
>> "
>
>
> If you have time, would you mind describing how the app works?
>
This is a fairly high view of our app and how it's architected but
hopefully it's a useful level of detail (I've mentioned it a couple of
times already but here's a rough gist of the folder/file structure we use
https://gis
Marek
This reply is only to my part. Did not read other parts.
> Maybe you've noticed that I haven't commented your example with
> reusability. That was on purpose because telling when and on what you
> should use it is completely different topic. For sure it can be used for
> integrating commun
Thanks Oliver! That's super helpful. <3
as well as providing a fully integrated UI which includes all of the
> features, we will also allow individual features to be embedded within
> particular pages e.g. an article might have a discussion embedded at the
> end, but that same discussion mini-a
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
afai
You've definitely given me some great advice along the way, I'm very
grateful!
I feel like this discussion has covered a few different scaling techniques
and I feel like there's a good time to use all of them. Perhaps it would be
good to just catalogue the different approaches along with some e
>
> I feel like this discussion has covered a few different scaling techniques
> and I feel like there's a good time to use all of them. Perhaps it would be
> good to just catalogue the different approaches along with some examples
> where people have found them useful in their projects.
>
Tha
Found it!
step : Int -> Parser Step
step i =
inContext ("step with indent " ++ (toString i)) <|
delayedCommitMap Step (oneStep i) <|
oneOf
[ repeat oneOrMore (lazy (\_ -> (step (i + 2
, succeed []
]
oneStep i =
in
I would add a dropdown.
Even a simple dropdown poses some interesting challenges to the
architecture:
- Dropdowns are ubiquitous in web apps.
- Dropdowns interact: when opening one, any other dropdown must close.
- Implementing keyboard support requires side effects and state.
- Dropdowns can hav
>
> I feel like this discussion has covered a few different scaling techniques
>> and I feel like there's a good time to use all of them. Perhaps it would be
>> good to just catalogue the different approaches along with some examples
>> where people have found them useful in their projects.
>>
>
>
14 matches
Mail list logo