On Monday, October 24, 2016 at 9:15:14 PM UTC+1, Peter Damoc wrote:
>
> I cannot provide sample code because I don't have a clear idea how the API
> could look.
>
> Think about the role that a ORM is playing. What I want to understand is
> what would a functional equivalent would look like in Elm.
>
So you got me thinking. There is actually a parallel between an ORM and the
client side using an API, because both work with complete data models but
only fetch and update parts of the complete model.
I OO programming, when something has not been fetched, the ORM proxies it.
So if you traverse to a proxies relation, the ORM automatically fetches it
for you. You can also size your queries to do a certain amount of
pre-fetching as your business logic settles into place and you strive to
optimize things.
I don't think there can be such a thing as transparent proxying in Elm
though? Since all HTTP requests require using the event driven system - in
order to trigger a request you must explicitly create a Cmd?
Take this as an example data model:
Type Passenger
= Passenger
{ name : String,
flights : List Flight
}
Type Flight
= Flight
{ flightNo: String,
passengers : List Passenger
}
Its not so convenient, since I cannot put off fetching the related
passengers or flights. With this model if I get one passenger, I need to
get all their flights and all their passengers and..
What I did was to use a Maybe
Type Passenger
= Passenger
{ name : String,
flights : Maybe (List Flight)
}
Type Flight
= Flight
{ flightNo: String,
passengers : Maybe (List Passenger)
}
but this feels a little dishonest to me, since Nothing should really mean
no Flights perhaps, even though I can use the empty list to stand for that.
I could instead have a type with Resolved and Unresolved constructors. Now
all I need is a function that takes an Unresolved, fetches its slice of
data, then updates the model to Resolved. If the server is supplying data
in a HAL type format, then resolving will have URLs to follow in order to
resolve data. Or if it is not a HAL type interface, the function needs to
be written (or generated) to fit the API it is using - it probably takes
some <id> and adds it to a URL it already knows to be the root of the API
that deals with that type.
As I say, I don't think we can make the remote fetching transparent unless
someone can tell me how that could be done in Elm? but providing a function
to resolve, especially if smart enough to encapsulate knowing where to
fetch the data and how to update the model with the result would make for
quite a slick user experience.
--
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.
