You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I had a look at the API for this package and was surprised there wasn't a toString: DataUri -> String function to complement the existing fromString function. Are there plans to add one?
I started working on a PR but then realized this was going to be more work than expected. Also I realized for my use case it's going to be too slow to parse the data URIs (I'm working with data URIs that are up to 256kb).
I did notice that you have a lot of unused dependencies in this package so I went ahead and made a PR removing those at least (though I seem to have broken something in CI, let me check on that first).
I started working on a PR but then realized this was going to be more work than expected. Also I realized for my use case it's going to be too slow to parse the data URIs (I'm working with data URIs that are up to 256kb).
Interesting. Any ideas how we could improve elm-data-uri to handle these cases, or are you going to use an alternative route to handle your use-case?
For my use case, I only need the data URI to be validated efficiently and I don't need to parse any of the information contained in it. I'm just getting a data URI from somewhere and then passing it along.
I suppose one way to make that work would be to add a fromStringLazy: String -> Maybe DataUri which validates the string but doesn't do any parsing until the user tries to read data from it (parsing the mediaType is probably fine though).
For my use case, I only need the data URI to be validated efficiently and I don't need to parse any of the information contained in it. I'm just getting a data URI from somewhere and then passing it along.
I suppose one way to make that work would be to add a fromStringLazy: String -> Maybe DataUri which validates the string but doesn't do any parsing until the user tries to read data from it (parsing the mediaType is probably fine though).
That would be cool, but perhaps it would be enough to have a validDataUri : String -> Bool or something?
I'm creating a package and the simplified API looks like this sendData : DataUri -> Cmd Msg. It could be sendData : String -> Cmd Msg but then the user could accidentally send in some nonsense string instead. So I do want to be able to wrap the string in DataUri after it's been validated. That isn't possible if I only have validDataUri : String -> Bool.
I'm not sure that would work. I'd still need to call () -> DataUri (the expensive step) before I could get the DataUri and send it along in an http request.
By fromStringLazy what I meant was something like this
type Data=Base64Bytes|RawString|LazyStringfromStringLazy:String->MaybeDataUrifromStringlazy dataUriText =if fastValidation dataUriText thenJust{ mediaType = getMediaTypeWhichShouldAlsoBeFast dataUriText
, data =Lazy dataUriText
}elseNothingtoString:DataUri->StringtoString dataUri =case dataUri.data of Lazy data -> data -- Also fastRaw data ->...Base64 data ->...
I'm not actually sure if this is a good idea. Adding a Lazy variant makes Data more annoying to use for anyone else using this package. Even if that's worthwhile, I think benchmarking needs to be done to be sure validation is fast enough and parsing is too slow. That's more work than I have time for so I think (at least for now) I'll just make a DataUri type in my package that doesn't do any parsing or validation and is just to help make sendData : DataUri -> Cmd Msg more understandable.
Activity
Munksgaard commentedon May 3, 2020
Hi @MartinSStewart! No, but there's no particular reason why there shouldn't be. Feel free to make a PR if you want to add it :-)
MartinSStewart commentedon May 3, 2020
I started working on a PR but then realized this was going to be more work than expected. Also I realized for my use case it's going to be too slow to parse the data URIs (I'm working with data URIs that are up to 256kb).
I did notice that you have a lot of unused dependencies in this package so I went ahead and made a PR removing those at least (though I seem to have broken something in CI, let me check on that first).
Munksgaard commentedon May 3, 2020
Interesting. Any ideas how we could improve elm-data-uri to handle these cases, or are you going to use an alternative route to handle your use-case?
MartinSStewart commentedon May 3, 2020
For my use case, I only need the data URI to be validated efficiently and I don't need to parse any of the information contained in it. I'm just getting a data URI from somewhere and then passing it along.
I suppose one way to make that work would be to add a
fromStringLazy: String -> Maybe DataUriwhich validates the string but doesn't do any parsing until the user tries to read data from it (parsing the mediaType is probably fine though).Munksgaard commentedon May 3, 2020
That would be cool, but perhaps it would be enough to have a
validDataUri : String -> Boolor something?MartinSStewart commentedon May 3, 2020
I'm creating a package and the simplified API looks like this
sendData : DataUri -> Cmd Msg. It could besendData : String -> Cmd Msgbut then the user could accidentally send in some nonsense string instead. So I do want to be able to wrap the string in DataUri after it's been validated. That isn't possible if I only havevalidDataUri : String -> Bool.Munksgaard commentedon May 3, 2020
So you need something like
fromStringLazy: String -> Maybe (() -> DataUri)? If you want to add it, you're more than welcome to :-)MartinSStewart commentedon May 3, 2020
I'm not sure that would work. I'd still need to call
() -> DataUri(the expensive step) before I could get the DataUri and send it along in an http request.By
fromStringLazywhat I meant was something like thisMunksgaard commentedon May 3, 2020
I see. As long as it doesn't change how the ordinary fromString and parser works, then I'm fine with it.
MartinSStewart commentedon May 3, 2020
I'm not actually sure if this is a good idea. Adding a
Lazyvariant makesDatamore annoying to use for anyone else using this package. Even if that's worthwhile, I think benchmarking needs to be done to be sure validation is fast enough and parsing is too slow. That's more work than I have time for so I think (at least for now) I'll just make aDataUritype in my package that doesn't do any parsing or validation and is just to help makesendData : DataUri -> Cmd Msgmore understandable.Munksgaard commentedon May 3, 2020
Fair enough.
Munksgaard commentedon May 3, 2020
I guess we can leave the issue open, a toString method wouldn't be out of the question.