>
> Doesn't seems like it would be much different from passing the ISO string
> through as I mentioned before. It just has the same tradeoffs of using a
> number to represent a Date.
>
True, if you know you get an ISO string, then they are essentially the
same. Convenience of each format depen
I think you are seeing the intended behavior. In the first example, you're
generating one Elm runtime that includes ModuleA and ModuleB, in the second
example, you're generating two different elm runtimes, and that's the
reason there isn't any name collision. You can easily check this by
compar
I'm wondering, wouldn't be enough to convert the date to a timestamp and
pass it as a Float to Elm? (and then use Date.fromTime inside Elm)
On Monday, 22 August 2016 18:59:18 UTC+2, OvermindDL1 wrote:
>
> On Monday, August 22, 2016 at 10:44:24 AM UTC-6, Kasey Speakman wrote:
>>
>> Re encoding: Y
Thanks Daniel.
That is a great example, thanks Markus! I hope to have some time next
> week to look at your example in more detail, but one thing I already
> noticed is that you don't explicitly deal with endianness. Have you
> verified that all your clients use the same
Regarding the binary encoder/decoder, our team is developing a SPA (mostly
native but slowly moving it to Elm) where the server uses binary strings to
encode large typed arrays inside json responses. These typed arrays are
encoded in base64 strings, and must be decoded depending on the data they
