Closed paluh closed 4 years ago
Some more loose thoughts:
Maybe I was wrong. Maybe on the highest level of the applets definition we want to even abstract over routing serialization and parsing and operate on types as routes and use some effect (like printUrl
) to serialize them and forget about routing duplex.
On the other hand I think that even on the highest level we should be able to use HTTP context like GET
and POST
form data and also raw request payload, headers etc. So we can provide some logic . We can assume representation for form data close to something like:
type FormData = Array (Tuple String String)
I'm closing this as it is too general and some parts of it are already solved I think.
I think that we should try to architect our "applets" in a way that we can reuse them easily between projects. What should be customizable:
Customize rendering (I'm still thinking here about
Variant
andRecord
as it automagicaly extends its row).Plug in the whole "applet" routing easily. This is probably already provided by routing duplex. I wonder if we would gain anything also here by using
Variant
for route representation instead of regular sum types but it seems that route printing function could be easily extensible then.Handling errors with Variant to have is also extensible.
I think that we don't want to abstract over db storage. We want to probably provide a base type with row for an
account
table likeAccout r
and use its closed versions in the views / queries - I meanAccount ()
. In this way we can have differentAccount
tables in different apps.The same probably goes for applets like "login applet" (with open id login through google / facebook, password reset etc.).
Further down the road we can even think about
cart
,payment
andorder
applets. We will see if these are feasible....