Parametrize query value container
Closed this issue · 4 comments
It seems that RFC 3986 doesn't specify exact format/semantics of query parts. I wonder if you are going to accept parameterization of query value container (Foldable + Alternative) - I've tried this on my branch (I'm pointing to appropriate diff). I'm not sure if I've taken appropriate approach or done it in the simplest possible manner... ;-)
With this additional parameter you can easily aggregate query values into List or use it with Maybe (but it changes current strategy and in case of repeated value it uses the first one).
What do you think?
The query stuff could definitely use some work as it is, but I'd been thinking about making it a list of tuples instead. Both preserving order and allowing duplicates seems like it could be useful, potentially, so seems like something basic like that might be the simplest way of dealing with any possible use case that could arise.
The constraint idea is pretty neat though!
I think that your proposition is a lot more reasonable than my constraints juggling (with my patch I've tried to be backwards- compatible and handle Maybe automagicaly).
Should I try again and provide another pull request where I would just replace StrMap (Maybe String) with List (Tuple String String) or are you planning to make some additional refactoring/changes with this type migration?
Sorry for the slow reply again... yes, please go ahead with a PR for a List-Tuple based representation. I don't have any other immediate changes I'd like to integrate.
This library definitely needs some love to make it really nice, and I think there are probably a few cases that don't parse that should. I've tried to plan out a few other approaches that would make invalid URLs unrepresentable in the types, etc. but so far haven't come up with anything (reasonable) - at some point I'll spend some more time on it again and figure something out (probably a smart constructor/fold approach rather than exposing the constructor internals), but for now it's mostly good enough to get the job done. All contributions to improve it are very welcome 😄
Sorry for the slow reply again...
No problem!
yes, please go ahead with a PR for a List-Tuple based representation. I don't have any other immediate changes I'd like to integrate.
Ok - I will work on it this week for sure as I need this change to improve my bidirectional (experimental) routers generator (https://github.com/paluh/purescript-routing-bob).
This library definitely needs some love to make it really nice (...)
It's really nice already - thanks for your work!
I've tried to plan out a few other approaches that would make invalid URLs unrepresentable in the types (...) All contributions to improve it are very welcome
I'm not sure if I able to help without any hints, but maybe... if your write your ideas down as an issues, then I would be able to implement some of them. I know that you have a lot of really important work on your shoulders (thanks for your work again - it's amazing!), so there is no hurry with this ;-)