Re: [elm-discuss] Re: Metalinguistic abstractions over databases

2016-10-21 Thread John Kelly 
Just to follow up on the limitations in my library I spoke about -- namely, 
not being able to represent the relationships *in *the resource definition. 
I spent a bit of time drafting up some potential api changes that would 
make it possible: here 
. 

Handling the recursive nature of relationships was influenced by 
Json.Decode.Extra.lazy 


On Friday, October 21, 2016 at 10:26:16 AM UTC-7, John Kelly wrote:
>
> Great Question!
>
> You can checkout an example here 
> . It 
> builds off of the example presented in the docs. 
>
> Currently, the library does not support representing relationships in the 
> Resource definition, however, the library *does *support representing the 
> relationships in the queries (see example). I'm not yet sure the best way / 
> whether it will be possible to represent the relationships in the Resource 
> definition. Would love to chat if you have any ideas!
>
>
>
> On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote:
>>
>> Hi John, 
>>
>> The project you linked to looks great. 
>> How do you deal with references? (entities referencing other entities)  
>>
>>
>>
>> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly  wrote:
>>
>>> I'm sorry to link drop, but I've been doing a bit of work on a library 
>>> to remove some of the boilerplate when writing client code for a REST API. 
>>> The library is currently locked in / specific to what is called PostgREST, 
>>> but I imagine that the patterns could be applied to any REST backend. Check 
>>> it out: https://github.com/john-kelly/elm-postgrest/
>>>
>>> The core idea is to remove the boilerplate of always having to define 
>>> encoder, decoder and schema. Would love to chat.
>>>
>>> --
>>> 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...@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] Structure for large Elm apps

2016-10-21 Thread Ed Ilyin 
Can you, please, provide an example?
When I do a component (like one page of my SPA), I dedicate a module for
it. So, how can look a flat structure? Just Shared.elm, Main.elm,
Update.elm and View.elm?

Il giorno ven 21 ott 2016 alle ore 20:22 Wouter In t Velt <
wouter.intv...@gmail.com> ha scritto:

> +1 for the "better flat than nested " approach.
> I think it was the second elm town podcast where Brian admitted that he
> actually regretted his post.
>
> From personal experience (admittedly limited) I definitely agree to the
> "flat is better than nested". Having one update function with helpers, and
> not having any components with local state has made debugging at least 10x
> faster for me.
>
> Adding features like an undo function was way easier with a flat structure.
>
> --
> 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] Re: Metalinguistic abstractions over databases

2016-10-21 Thread John Kelly 
Great Question!

You can checkout an example here 
. It 
builds off of the example presented in the docs. 

Currently, the library does not support representing relationships in the 
Resource definition, however, the library *does *support representing the 
relationships in the queries (see example). I'm not yet sure the best way / 
whether it will be possible to represent the relationships in the Resource 
definition. Would love to chat if you have any ideas!



On Friday, October 21, 2016 at 1:25:10 AM UTC-7, Peter Damoc wrote:
>
> Hi John, 
>
> The project you linked to looks great. 
> How do you deal with references? (entities referencing other entities)  
>
>
>
> On Thu, Oct 20, 2016 at 9:19 PM, John Kelly  > wrote:
>
>> I'm sorry to link drop, but I've been doing a bit of work on a library to 
>> remove some of the boilerplate when writing client code for a REST API. The 
>> library is currently locked in / specific to what is called PostgREST, but 
>> I imagine that the patterns could be applied to any REST backend. Check it 
>> out: https://github.com/john-kelly/elm-postgrest/
>>
>> The core idea is to remove the boilerplate of always having to define 
>> encoder, decoder and schema. Would love to chat.
>>
>> --
>> 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...@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] Structure for large Elm apps

2016-10-21 Thread Wouter In t Velt 
+1 for the "better flat than nested " approach.
I think it was the second elm town podcast where Brian admitted that he 
actually regretted his post.

>From personal experience (admittedly limited) I definitely agree to the "flat 
>is better than nested". Having one update function with helpers, and not 
>having any components with local state has made debugging at least 10x faster 
>for me.

Adding features like an undo function was way easier with a flat structure.

-- 
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] Re: How do you name messages?

2016-10-21 Thread art yerkes 
I'd be on board with using both:

case action of
   ...
   ClickRegistrationSubmit form ->
  let vErrors = validate form in
  vErrors 
|> Maybe.map (\ve -> update (ShowValidationErrors ve))
|> Maybe.withDefault (update (SubmitForm form))

separates concerns and levels of abstraction
each message has clear intent
validation errors coming back from the server could follow the same path as 
local validation errors
SubmitForm doesn't need to decide whether to submit a form

On Friday, October 21, 2016 at 7:56:04 AM UTC-7, Birowsky wrote:
>
> Well, they leaned towards the second approach. The reason was: *what if 
> that action is not possible*. 
>
> What if on SubmitForm, instead of sending the registration form, the app 
> would need to display validation errors? 
>
> I see that ambiguity. But from this perspective, it doesn't seem like a 
> burden to me. 
>
> I would, however, like to know where do experienced elm devs lean on. Does 
> the first approach cause ambiguity when working in a team?
>
>

-- 
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] Re: How to preventDefault on keyup of a specific key?

2016-10-21 Thread OvermindDL1 
On-going conversation about how to handle that (in my opinion an 
`onWithOptions` should not 'take' options but rather should return them 
along with the message as a tuple, but it does not function that way 
currently).  The current work-around is to use ports (register your event 
listener in javascript after an initial render then call back in to elm 
from the event callback via 'push').

On Friday, October 21, 2016 at 9:18:45 AM UTC-6, Jacky See wrote:
>
> In the js version of the code would look like
>
>
> el.addEventListener('keyup', function(ev){
> if(ev.keyCode == 32){
> ev.preventDefault();
> }
> });
>
>
> Can't seems to do that in current Html.Events.onWithOptions
>

-- 
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] How to preventDefault on keyup of a specific key?

2016-10-21 Thread Jacky See 
In the js version of the code would look like


el.addEventListener('keyup', function(ev){
if(ev.keyCode == 32){
ev.preventDefault();
}
});


Can't seems to do that in current Html.Events.onWithOptions

-- 
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] Proposal: Rename case..of -> match..with

2016-10-21 Thread Wouter In t Velt 
Personally I prefer "case ... of"

I find it easier to read: "(in) case [this thing] (is) of [this pattern], (do) 
[this function]".
It is a variant of the "if ... then ... else .." syntax.

To me, "match ... with" would be less easy to read (although other languages 
apparently use it), but also more confusing: "match [this] with [that]" also 
suggests "make [this] equal to [that]"

-- 
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] Re: How do you name messages?

2016-10-21 Thread Birowsky 
Well, they leaned towards the second approach. The reason was: *what if 
that action is not possible*. 

What if on SubmitForm, instead of sending the registration form, the app 
would need to display validation errors? 

I see that ambiguity. But from this perspective, it doesn't seem like a 
burden to me. 

I would, however, like to know where do experienced elm devs lean on. Does 
the first approach cause ambiguity when working in a team?

-- 
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] Re: Can I throw strings at the elm compiler?

2016-10-21 Thread Joey Eremondi 
Maybe take a look at what the Atom and Light table modes do? They both do
something like this.

On Oct 21, 2016 6:57 AM, "art yerkes"  wrote:

> Recently, I've been working on a cradle for the compiler that can serve as
> an example for your use case
>
> https://github.com/prozacchiwawa/elm-basic-compile
>
> On Thursday, October 20, 2016 at 9:47:28 PM UTC-7, Adam Fluke wrote:
>>
>> So I know that answer may be no, but I thought I'd ask incase I missed
>> something.
>>
>> The short question version of the question:
>>
>> Can I pass strings to the elm compiler to see if they will compile
>> without writing to a file?
>>
>> The long version of the question:
>>
>> I love idea of machine generated code, and have been exploring applying
>> evolutionary biology principles to code generation. In node, this required
>> throwing things at unit tests, but it was really slow for a number of
>> reasons. So the exploration has idled. Now I have been learning/toying with
>> elm and thought, "This would be perfect for evolutionary code search, I
>> only have to run tests on code that compiles, meaning 99% never going to
>> work mutations are cheaply discarded, and the 1% can be tested."
>>
>> The psuedo code in my head:
>>
>> hey elm compiler
>>
>>
>>
>> --
> 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.

[elm-discuss] Re: Can I throw strings at the elm compiler?

2016-10-21 Thread art yerkes 
Recently, I've been working on a cradle for the compiler that can serve as 
an example for your use case

https://github.com/prozacchiwawa/elm-basic-compile

On Thursday, October 20, 2016 at 9:47:28 PM UTC-7, Adam Fluke wrote:
>
> So I know that answer may be no, but I thought I'd ask incase I missed 
> something. 
>
> The short question version of the question:
>
> Can I pass strings to the elm compiler to see if they will compile without 
> writing to a file?
>
> The long version of the question:
>
> I love idea of machine generated code, and have been exploring applying 
> evolutionary biology principles to code generation. In node, this required 
> throwing things at unit tests, but it was really slow for a number of 
> reasons. So the exploration has idled. Now I have been learning/toying with 
> elm and thought, "This would be perfect for evolutionary code search, I 
> only have to run tests on code that compiles, meaning 99% never going to 
> work mutations are cheaply discarded, and the 1% can be tested."
>
> The psuedo code in my head:
>
> hey elm compiler
>
>
>
>

-- 
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] Re: How do you name messages?

2016-10-21 Thread Simone Vittori 
Why not both?

Usually I find myself using the first approach more, especially when I have 
"actions" coming from the view (e.g. ChangeInput, SubmitForm).

However I also use the second approach when I get some value back from a 
task (e.g. ParsedInput, ReceivedData).

On Friday, 21 October 2016 09:10:34 UTC+1, Birowsky wrote:
>
> In the latest ElmTown episode they had this discussion, which seems like a 
> valid one, but i couldn't catch any good pro or con argument.
>
> So the two approaches are:
>
>
>- What is the system supposed to do: RegisterWithCredentials String 
>String
>- What happened in the system: ClickRegistrationSubmit String String / 
>TapRegistrationSubmit String String
>
>
> Let's have an argumented discussion around this :}
>

-- 
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] Re: Metalinguistic abstractions over databases

2016-10-21 Thread Peter Damoc 
Hi John,

The project you linked to looks great.
How do you deal with references? (entities referencing other entities)



On Thu, Oct 20, 2016 at 9:19 PM, John Kelly  wrote:

> I'm sorry to link drop, but I've been doing a bit of work on a library to
> remove some of the boilerplate when writing client code for a REST API. The
> library is currently locked in / specific to what is called PostgREST, but
> I imagine that the patterns could be applied to any REST backend. Check it
> out: https://github.com/john-kelly/elm-postgrest/
>
> The core idea is to remove the boilerplate of always having to define
> encoder, decoder and schema. Would love to chat.
>
> --
> 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.