The Gruntfile is pretty scary! That's really the thing with webcomponents I
think: the boilerplate is quite huge...
On Tuesday, March 28, 2017 at 5:50:13 PM UTC+2, Rupert Smith wrote:
>
> On Tuesday, March 28, 2017 at 2:04:22 PM UTC+1, Charles-Edouard Cady wrote:
>>
>> I trie
Wonderful! It works! Nice & green!
On Tuesday, March 28, 2017 at 5:50:13 PM UTC+2, Rupert Smith wrote:
>
> On Tuesday, March 28, 2017 at 2:04:22 PM UTC+1, Charles-Edouard Cady wrote:
>>
>> I tried your application on Iceweasel. The checkboxes never get checked,
>>
There's a polyfill for non-chrome browsers:
https://github.com/WebComponents/webcomponentsjs
Haven't tested it with your code though.
On Tuesday, March 28, 2017 at 5:45:49 PM UTC+2, Rupert Smith wrote:
>
> On Tuesday, March 28, 2017 at 2:04:22 PM UTC+1, Charles-Edouard Cady wrote:
&
8, 2017 at 10:21:02 AM UTC+1, Rupert Smith wrote:
>>
>> On Tuesday, March 28, 2017 at 7:26:37 AM UTC+1, Charles-Edouard Cady
>> wrote:
>>>
>>> (2) the ability to write webcomponents in Elm.
>>>
>>> I'm not too sure about number 2: what I've s
tributes.
Once again, thank you: you just saved me a lot of time!
On Tuesday, March 28, 2017 at 12:15:35 PM UTC+2, Rupert Smith wrote:
>
> On Tuesday, March 28, 2017 at 10:21:02 AM UTC+1, Rupert Smith wrote:
>>
>> On Tuesday, March 28, 2017 at 7:26:37 AM UTC+1, Charles-Edouard
I'm composing a single-page application from several microservices
back-ends. Each back-end should render a part of the page.
Right now I'm considering using webcomponents:
- main page is in Elm and subscribes to a websocket giving it the list of
microservices it can get webcomponents from
-
Would anybody besides me be interested in being able to manipulate module?
I was thinking something on the lines of:
getUpdate : m -> (m.Model -> m.Msg -> m.Model)
getUpdate module =
module.update
Then if you have a module, say
module Counter exposing (update, Msg, Model)
type Model = Int
I have the feeling that some people think if you can't do it simply without
a local state then use a ready-made external component. Maybe that's the
answer after all - I don't know.
I was once told that design patterns exist to address the shortcomings of a
language & I think it's quite true:
On Sunday, August 28, 2016 at 10:14:43 AM UTC+2, Richard Feldman wrote:
>
> Components should only update their own private non-shared state that
>> other components don't need. Shared states such as your server queue are
>> updated at the highest level and each sub component merely receives a
Brilliant! Thanks a lot!
To summarise what I understood:
- A component should only update its internal states
- All updates of shared states should be done at a higher level
which could be further summarised in:
A state should only be updated by its owner (i.e. the highest component
where that
Thanks a lot, Richard, it makes much more sense now!
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options,
While I understand that not breaking things up too often is sound advice in
elm, I still think this doesn't answer my question: you're basically saying
"you're doing it way too often" but you're not saying "don't do it at all" so I
do need to find a scalable way of doing it a bit. The problem I
I had the same problem for a calendar widget: I wanted to hide the calendar
whenever you click outside of it.
What I ended up doing was using a big fat ugly modal div and change its
z-offset:
renderWidget : Model -> Html Msg
renderWidget model =
let
big_fat_modal : Html Msg
13 matches
Mail list logo
