Re: [elm-discuss] Why not components?
Thanks for solving this mystery for us David. It probably is sensible to avoid anyway: if someMaybe == ... then And use case someMaybe of (Or .map) instead. Gives us more protection from the compiler to get all branches covered... -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
They have equality but not comparison. They can't be used as a Dict key, for instance. On Dec 5, 2016 5:39 PM, "Peter Damoc" wrote: > This is weird. > For some reason I got it into my head that tags are not comparable. > Now I can't remember when or why. > > The code seams to work on my end too and for my sanity I checked it on > 0.17 and 0.16 and it works in those versions too. > weird. > > > > > On Mon, Dec 5, 2016 at 11:59 PM, Wouter In t Velt < > wouter.intv...@gmail.com> wrote: > >> Op maandag 5 december 2016 22:51:02 UTC+1 schreef Peter Damoc: >>> >>> You cannot use comparison on tags. >>> >> >> I can see your version is cleaner. >> Do you mean a comparison with a maybe is not allowed? Like this? >> -- is this not allowed? >> if someMaybe == Just 42 then >> ... >> >> The original change I made did seem to work at my end, and the compiler >> didn't complain.. >> Or is it convention rather than rule? >> >> -- >> 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, visit https://groups.google.com/d/optout. >> > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > > -- > 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, visit https://groups.google.com/d/optout. > -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
This is weird. For some reason I got it into my head that tags are not comparable. Now I can't remember when or why. The code seams to work on my end too and for my sanity I checked it on 0.17 and 0.16 and it works in those versions too. weird. On Mon, Dec 5, 2016 at 11:59 PM, Wouter In t Velt wrote: > Op maandag 5 december 2016 22:51:02 UTC+1 schreef Peter Damoc: >> >> You cannot use comparison on tags. >> > > I can see your version is cleaner. > Do you mean a comparison with a maybe is not allowed? Like this? > -- is this not allowed? > if someMaybe == Just 42 then > ... > > The original change I made did seem to work at my end, and the compiler > didn't complain.. > Or is it convention rather than rule? > > -- > 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, visit https://groups.google.com/d/optout. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
Op maandag 5 december 2016 22:51:02 UTC+1 schreef Peter Damoc: > > You cannot use comparison on tags. > I can see your version is cleaner. Do you mean a comparison with a maybe is not allowed? Like this? -- is this not allowed? if someMaybe == Just 42 then ... The original change I made did seem to work at my end, and the compiler didn't complain.. Or is it convention rather than rule? -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
On Mon, Dec 5, 2016 at 8:38 PM, Wouter In t Velt
wrote:
> Looks great! I would suggest a small change in the country update: to only
> reset the city selector if the country selected is different from the
> previous selection.
>
> CountryPicked country ->
> { model
> | country = Just country
> , city =
> if model.country /= Nothing && model.country /= Just
> country then
> Nothing
> else
> model.city
> }
>
>
You cannot use comparison on tags. But I have updated the code to reflect
the requested functionality. It looks like:
CountryPicked country ->
{ model
| country = Just country
, city =
model.country
|> Maybe.andThen
(\currentCountry ->
if currentCountry == country then
model.city
else
Nothing
)
}
--
There is NO FATE, we are the creators.
blog: http://damoc.ro/
--
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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
I started out with a bunch of parameters but if I have more than 3 parameters in a function I tend to move towards using a record. As I already pointed out, the API smells. :-) On Mon, 5 Dec 2016 at 20:40, Wouter In t Velt wrote: > Peter, did you deliberately choose to put everything (including items) in > a single config record? > Just curious. > > -- > 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, visit https://groups.google.com/d/optout. > -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
Peter, did you deliberately choose to put everything (including items) in a single config record? Just curious. -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
Op maandag 5 december 2016 16:58:34 UTC+1 schreef Peter Damoc:
>
> I just pushed the latest changes and the functionality should be
> equivalent.
> https://github.com/pdamoc/polymer-exploration
>
Looks great! I would suggest a small change in the country update: to only
reset the city selector if the country selected is different from the
previous selection.
CountryPicked country ->
{ model
| country = Just country
, city =
if model.country /= Nothing && model.country /= Just
country then
Nothing
else
model.city
}
Would have liked to get some sort of onSelectedChanged event working, but
even though the event is in the elm-polymer library, I had no luck getting
it to work.
Also, would have loved to make a pull request for you repository on github,
but I worry that my pull request would include the gazillion bower and npm
installs as well.
Sorry, I'm a noob at github too.
--
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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
This looks very promising! I really like the fact that the web components solution takes care of the blur stuff, so it makes model cleaner and we can do away with the subscription. I have to do some more digging, but I like the fact that there's a ton of event handlers, that you can simply include in your elm view render. -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
I just pushed the latest changes and the functionality should be equivalent. https://github.com/pdamoc/polymer-exploration I have paid very little thought to the Dropdown's API and so it's bad but... it get's the job done. Also, I was getting some weird JSON errors when I tried to use official `onIronSelect` and so I just hacked everything to use the onClick. These hacks are less important right now as this is the job of the library developer. >From a library user point of view however, I think that the web-components version is remarkably better. With a battery of great looking and easy to combine components like these, one could quickly implement great looking layouts AND, more importantly, quickly alter them without having to change code in multiple places. On Mon, Dec 5, 2016 at 4:54 PM, Wouter In t Velt wrote: > Wow you guys are fast! > Hopefully I can dive into it tonight (@work right now). > > I think it would be really interesting to see a webcomponents version of > the same example and compare it with the other two versions. > > In the meantime, do let me know if there's anything I could improve about > my other implementation of the 2 versions. > You are no doubt way more seasoned in Elm than I am, so I am sure my code > can be improved. > > -- > 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, visit https://groups.google.com/d/optout. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
Wow you guys are fast! Hopefully I can dive into it tonight (@work right now). I think it would be really interesting to see a webcomponents version of the same example and compare it with the other two versions. In the meantime, do let me know if there's anything I could improve about my other implementation of the 2 versions. You are no doubt way more seasoned in Elm than I am, so I am sure my code can be improved. -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
On Mon, Dec 5, 2016 at 4:20 PM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > Not sure what the problem is, perhaps just styling? I have defeintely been > able to get paper-listbox and paper-item working. See: > > http://www.thesett.com/style-lab/#multiselect > Well... duh... I forgot to import them. I'll try to finish the implementation and get back. -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
On Monday, December 5, 2016 at 1:05:32 PM UTC, Peter Damoc wrote: > > After I found out about elm-polymer library, I tried to reimplement your > example but, I've run into issues. > > This is as far as I got > https://github.com/pdamoc/polymer-exploration > > The problems are due to the way children are handled. > I tried a fix that I remembered from a previous exploration (lazyRegister) > but, the rendering is still bad. > Not sure what the problem is, perhaps just styling? I have defeintely been able to get paper-listbox and paper-item working. See: http://www.thesett.com/style-lab/#multiselect Relevant source files: https://github.com/rupertlssmith/thesett_style_lab/blob/master/src/elm/MultiSelect/View.elm https://github.com/rupertlssmith/thesett_style_lab/blob/master/src/index.html -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
Wouter, After I found out about elm-polymer library, I tried to reimplement your example but, I've run into issues. This is as far as I got https://github.com/pdamoc/polymer-exploration The problems are due to the way children are handled. I tried a fix that I remembered from a previous exploration (lazyRegister) but, the rendering is still bad. This is yet another reason I think that Polymer might not be the best way forward. A native Elm solution to Web Components might produce better results both in therms of developer UX and in terms of final deliverables. On Sun, Dec 4, 2016 at 5:51 PM, Wouter In t Velt wrote: > Op zondag 4 december 2016 15:43:40 UTC+1 schreef Peter Damoc: >> >> You're trading one set of boilerplate for another. >> > > Fair enough. I could have pointed that out in the conclusions. > > Both your versions are almost as bad as you are forcing internal details >> of the functioning of the dropdown onto the user of the dropdown. >> > > Could you explain this? I am not sure I follow what you are saying here. > Wouldn't we always enforce some kind of API from the dropdown on the user? > Or what would need to be different in both versions to not "force > internals .. onto the user" ? > > The pure version is indeed more aligned with the current recommendations >> but it is almost as bad from a library user point of view. >> > > Taking the pattern and consequences from a dropdown to a library is > something that I did not consider. Maybe I should have. > > >> In order to have a full treatment of the issue, implement a >> webcomponents/polymer version of the same functionality and then argue that >> the "pure" version is better. >> > > By no means did I intend to make a full treatment of the issue, or claim > that pure is always better than stateful. > Admittedly, the wording of the last paragraphs was too strong, so I > changed that. > > I follow the uptake of integrating web components/ polymer with much > interest. > The argument in the article was made specifically where the dev is > building everything in elm, and wants to structure his/her code when the > app grows. > The implementation of a Polymer version is a different scenario IMHO. > But thank you for the challenge, I'll look into it ;) > > > > -- > 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, visit https://groups.google.com/d/optout. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
A tiny note: To avoid the confusing inclusion of `Position` in `Blur`, you can remove the `Position` and pass `always Blur` to `Mouse.clicks`. On Sun, Dec 4, 2016 at 10:51 AM, Wouter In t Velt wrote: > Op zondag 4 december 2016 15:43:40 UTC+1 schreef Peter Damoc: >> >> You're trading one set of boilerplate for another. >> > > Fair enough. I could have pointed that out in the conclusions. > > Both your versions are almost as bad as you are forcing internal details >> of the functioning of the dropdown onto the user of the dropdown. >> > > Could you explain this? I am not sure I follow what you are saying here. > Wouldn't we always enforce some kind of API from the dropdown on the user? > Or what would need to be different in both versions to not "force > internals .. onto the user" ? > > The pure version is indeed more aligned with the current recommendations >> but it is almost as bad from a library user point of view. >> > > Taking the pattern and consequences from a dropdown to a library is > something that I did not consider. Maybe I should have. > > >> In order to have a full treatment of the issue, implement a >> webcomponents/polymer version of the same functionality and then argue that >> the "pure" version is better. >> > > By no means did I intend to make a full treatment of the issue, or claim > that pure is always better than stateful. > Admittedly, the wording of the last paragraphs was too strong, so I > changed that. > > I follow the uptake of integrating web components/ polymer with much > interest. > The argument in the article was made specifically where the dev is > building everything in elm, and wants to structure his/her code when the > app grows. > The implementation of a Polymer version is a different scenario IMHO. > But thank you for the challenge, I'll look into it ;) > > > > -- > 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, visit https://groups.google.com/d/optout. > -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
Op zondag 4 december 2016 15:43:40 UTC+1 schreef Peter Damoc: > > You're trading one set of boilerplate for another. > Fair enough. I could have pointed that out in the conclusions. Both your versions are almost as bad as you are forcing internal details of > the functioning of the dropdown onto the user of the dropdown. > Could you explain this? I am not sure I follow what you are saying here. Wouldn't we always enforce some kind of API from the dropdown on the user? Or what would need to be different in both versions to not "force internals .. onto the user" ? The pure version is indeed more aligned with the current recommendations > but it is almost as bad from a library user point of view. > Taking the pattern and consequences from a dropdown to a library is something that I did not consider. Maybe I should have. > In order to have a full treatment of the issue, implement a > webcomponents/polymer version of the same functionality and then argue that > the "pure" version is better. > By no means did I intend to make a full treatment of the issue, or claim that pure is always better than stateful. Admittedly, the wording of the last paragraphs was too strong, so I changed that. I follow the uptake of integrating web components/ polymer with much interest. The argument in the article was made specifically where the dev is building everything in elm, and wants to structure his/her code when the app grows. The implementation of a Polymer version is a different scenario IMHO. But thank you for the challenge, I'll look into it ;) -- 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, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Why not components?
On Sun, Dec 4, 2016 at 1:50 PM, Wouter In t Velt wrote: > Any feedback would be welcome! > > You're trading one set of boilerplate for another. Both your versions are almost as bad as you are forcing internal details of the functioning of the dropdown onto the user of the dropdown. The pure version is indeed more aligned with the current recommendations but it is almost as bad from a library user point of view. In the 5 months since this pattern emerged I have not seen an explosion of "not-a-component" libraries that follow it. In order to have a full treatment of the issue, implement a webcomponents/polymer version of the same functionality and then argue that the "pure" version is better. -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- 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, visit https://groups.google.com/d/optout.
[elm-discuss] Why not components?
Hi All, To explore and explain (in a beginner-friendly way) why making stateful reusable components in Elm is not always a good idea, I have made a demo + write-up in 2 articles over on Medium. Here are the links to the drafts: https://medium.com/@wintvelt/a-reusable-dropdown-in-elm-part-1-d7ac2d106f13 https://medium.com/@wintvelt/a-reusable-dropdown-in-elm-part-2-9659ef988441 Any feedback would be welcome! -- 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, visit https://groups.google.com/d/optout.
