Posts

Showing posts from December, 2018

zio and scalatest

zio and scalatest If you use scalatest with zio , you need to recognize that there are a few ways to hook up scalatest. In the end, the problem is that scalatest uses exceptions to signal failure and that does not really work well with a library that models errors explicitly (or fp in general which treats errors as values). Some notes: scalatest has two async-test error channels–throwing an exception in open code and putting an exception into a Future . You can throw an exception or return an Assertion . The Assertion can be true or not true. However, a failed Assertion really just throws a TestFailedException immediately there is no “failed” Assertion value. You can get about as much debugging information from throwing an exception as you do an Assertion if you convert the zio Cause to a string. You can run async tests but you need to return a Future[Assertion]. I wanted to keep everything async so I could run this in JS when that’s available for zio. scala...

why I like scala.js

why I like scala.js scala.js is a scala compiler that compiles scala to javascript. There are many languages out there that compile to javascript. So why do I like scala.js? You’ll see that my argument could probably be made for other transpilation-capable languages as well. In no particular order: I already know scala so this allows me to re-use my skills. I was tired of JVM issue and uncertainties about its future. Although Oracle now seems to be investing in the JVM ecosystem, I am wary of historical trends. Also, the JVM is not critical in some types of program architectures. The other aspect is that scala has remnants of the JVM built into it. Life is tough, but I found that JS handles some things differently that I liked better, such as not forcing errors into a specific type (JVM only allows errors to be Throwables). Built on javascript, scala.js interop with javascript allows me to remove a large category of thorny issues that nearly all JVM language...

abstracting a react data fetcher in scala.js with cats, cats-effect

abstracting a react data fetcher in scala.js with cats, cats-effect Problem I put together a library for my small scala.js reasonreact-like facade scalajs-react that reflects the ReasonReact react component interface. When you use this facade to build web user interfaces you still need to fetch data. You have many choices for building a fetcher component including using an application state management library like redux/mobx or scala.js-based diode . The reasonreact component API includes a “reducer” built into every component so let’s just use that capability since its builtin and simple. I’ve found that with the builtin reducer, the need for global application state management is greatly reduced. If we can use a solid effects library then we should be all set. react@next has suspense and lazy loading. Unfortunately, these are not available in scala.js and may never be efficient in scala.js because scala.js cannot be easily compiled into separate “modules” wit...