@SystemFw I made that with your exemple https://gist.github.com/crakjie/7398a57124690f09a7e2037fc3112457 I still have to try it next week but I'm quite happy.
I was lucky that when looking for a state machine with
I was lucky that when looking for a state machine with
Ref+ Deferred you actually already made one !
(and if they don't too bad for them, I did appreciate it, so I'm gonna share it no matter if the do or don't xD )
I don't have a talk specifically on that, but I do cover it in a few talks (shared state in pure FP, my fs2 talk at klarna), I do have a long reddit post on it though. If you browse through https://systemfw.org/talks and https://systemfw.org/writings you should find all the links you need
the reddit posts are called "the benefits of IO"
I think it's the one from Italy, so Shared State in Pure FP :) thanks, mate
@LukaJCB I do, but in more up-to-date ones :)
you’re best of just writing your own
Bracket instance
Anyways thank you.
in fact there could be a
Bracket for any MonadError
getting the prioritization right would be tricky though
(ResourceProxy stuff we’ve discussed a few times)
I would like to seek help refactoring this code. I don't know if should wrap the ValidatedNec to IO or what... I also wanted to have a logger on every validation.
type ValidationResult[A] = ValidatedNec[JobPostError, A]
override def createJobPost(
newJobPost: JobPost
): IO[ValidatedNec[String, JobPost]] = {
// TODO: Add logger here on every field validation
val localValidation: ValidationResult[JobPost] = (
validateNoop(newJobPost.id),
validateEmptiness("Job post title".some, newJobPost.title),
validateEmptiness("Job post description".some,
newJobPost.description),
validateNoop(newJobPost.createdAt),
validateNoop(newJobPost.modifiedAt)
).mapN(JobPost)
val databaseValidations: IO[ValidationResult[JobPost]] = (for {
_ <- Logger[ConnectionIO].info("Validating job title")
title <- validateTitleExistence(newJobPost)
_ <- Logger[ConnectionIO].info("Validating job description")
description <- validateNoop(newJobPost.description).pure[ConnectionIO]
createdAt <- validateNoop(newJobPost.createdAt).pure[ConnectionIO]
modifiedAt <- validateNoop(newJobPost.modifiedAt).pure[ConnectionIO]
id <- validateNoop(newJobPost.id).pure[ConnectionIO]
} yield {
(id, title, description, createdAt, modifiedAt).mapN(JobPost)
}).transact(xa)
val response: IO[ValidatedNec[String, JobPost]] =
localValidation match {
case Valid(_) => databaseValidations.map(_.leftMap(_.map(_.errorMessage)))
case Invalid(e) => e.map(_.errorMessage).invalid[JobPost].pure[IO]
}
response
}
Or is there much better way to do this in case that I just want to validate some of the case class fields?
actually you never use the
Valid case in your result, so you don't even need the last clause
@underscore05: See https://stackoverflow.com/questions/37980300/use-shapeless-to-merge-two-instances-of-the-same-case-class/37981448#37981448 for example.
Or
Band
Is there any sort of stance on adding "duplicate" methods in more discoverable locations? An example I'm thinking of is adding
IO.parSequence or parSequenceN. It's not immediately obvious where that behavior lives if you're using IO directly and not the typeclasses. Even with the typeclasses, parSequence and parSequenceN for example exist in different typeclasses, and it's not necessarily obvious to a newcomer why that might be
I'm writing some aimed-at-beginners info around
IO and some cases like that make things less discoverable than I'd want it to be
Other examples might be typeclass methods/syntax on
IO as direct methods; things like >> or adaptError