On Thursday, March 2, 2017 at 1:30:44 AM UTC, Francesco Orsenigo wrote:
>
> 2)
> In my current project, I need to edit a "Rule" record.
> The app has already a "Rule" type, which *must* have an "id", because
> that's how the data arrives from the DB and is displayed to the user.
> However, the form to edit a Rule will need a different type, because
> depending on whether I am creating a new rule or editing an existing one,
> it may or may not have an "id".
>
I have the same issue. All I did was to make the id a Maybe String.
When a record arrives from the server, having been looked up in the
database, it contains id = Just "1234".
When I am creating a new record in the application to add to the database,
it contains id = Nothing.
That way I am able to use the same record for both purposes.
Another way is to define your record as a tuple (or a record of records or
a union type constructor with >1 arg):
type alias MyEntity = ( Id, Fields)
type alias MyEntity = { id : Id, fields : Fields)
type MyEntity = Entity Id Fields
type MyEntity =
Persistent Id Fields
| Ephemeral Fields
Are some possible data modelling options for your problem.
It might be nice to have some syntactical sugar to add and remove fields
from records easily, to produce new types. Perhaps it might encourage more
fragmented data modelling though? instead of designing a Type that is
sufficient to handle the whole problem.
P.S. I put the Maybe String for ids in my db records as a quick solution to
the problem, but even at the time I was aware that there are more options
that might need to be spelled out explicitly. Suppose you have a db record
that hold a reference to another record, do you also fetch that record? or
do you just fetch a link (reference) to it? or do you not fetch it at all?
or does it not even exist? So maybe when one record holds a reference to
another, all the options need to be spelled out in a union type:
type Ref a =
None
| DontKnow
| Link String
| Value a
--
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.