I guess you weren't explicitly defining type aliases for those records. But still, I think you might be able to salvage the API if you wrap the records in union type constructors.
On Sun, Oct 23, 2016 at 6:10 PM, Nick H <[email protected]> wrote: > If you are trying to make a recursive type definition, you need to use > union types. > > E.G. This is not OK: > > type alias Session = { speaker : Speaker } > type alias Speaker = { sessions : List Session } > > But this will compile. > > type Session = Session { speaker : Speaker } > type Speaker = Speaker { sessions : List Session } > > Think of a type alias as a kind of search-and-replace. A recursive type > alias leads to a never-ending search-and-replace process. > > > > On Sun, Oct 23, 2016 at 5:17 PM, John Kelly <[email protected]> wrote: > >> I'm coming to the sad realization that an api like this is simply not >> possible: >> >> ``` >> session = >> resource "sessions" >> { id = int "id" >> , speaker_id = int "speaker_id" >> , start_time = string "start_time" >> , end_time = string "end_time" >> , location = string "location" >> , session_type = int "session_type" >> , speaker = hasOne (\_ -> speaker) >> } >> >> >> speaker = >> resource "speakers" >> { id = int "id" >> , name = string "name" >> , sessions = hasMany (\_ -> session) >> } >> ``` >> >> Any ideas? I was under the impression that the lambda would fix the >> recursive type issue, but now i see that elm still has trouble with the >> type of the record. >> >> On Friday, October 21, 2016 at 10:08:07 PM UTC-7, John Kelly wrote: >>> >>> 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 >>> <https://gist.github.com/john-kelly/8ac5aa5d5e38bd148b70e10b0c44408c>. >>> >>> Handling the recursive nature of relationships was influenced by >>> Json.Decode.Extra.lazy >>> <http://package.elm-lang.org/packages/circuithub/elm-json-extra/latest/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 >>>> <https://gist.github.com/john-kelly/00424de66be03d9bbb07795b11c39a48>. >>>> 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 <[email protected]> >>>>> 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 [email protected]. >>>>>> 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 [email protected]. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
