Querki Open Source Projects
Querki itself is a commercial project -- we're trying to make some real money here. So its license is Open but Restricted -- basically, you can only create your own Querki sites for non-commercial use.
However, we've benefited a lot from the open-source world and want to give back to it. So we are gradually lifting useful utilities and libraries out of Querki, and putting them under the querki.org domain. Those libraries all use the MIT license, the most open and unrestricted license around. We encourage you to use these as you see fit. And if you see other bits of Querki that you think would be useful to you, don't hesitate to ask -- we're happy to share most of the commonly-useful parts.
Click on any of the headers below to be taken to their GitHub repositories.
This is a small library of useful common functions for use with Scala.js. As of now, this contains two main parts:
- RichFuture -- an enhanced Future that uses the JS infrastructure to easily manage things like timeouts.
- JSOptionBuilder -- a pattern that makes it easier to construct facades for complex JavaScript "option" objects, especially ones that use hard-to-represent-in-Scala type unions. (This is particularly useful when working with complex jQuery libraries, which frequently do this.)
jQuery is probably the single most important library in the JavaScript world, and Scala.js projects often want to make use of it. Scala.js has had a facade project named scala-js-jquery for a long time; that works, but it is quite loosely typed, which can make it frustrating for heavy use. jquery-facade is a complete rewrite. It is not complete as of this writing, but it is much more strongly typed, so it works better in IDEs and provides a lot more of that type-safety goodness.
Pull requests are welcomed in all of our open-source projects, but especially this one: we'd love to finish getting it fleshed-out and complete.
One of the most useful patterns in akka is "ask", but it is also one of the most dangerous -- since ask returns a Future that runs at an arbitrary time (usually not during the Actor's receive loop), using ask inside of an Actor can easily violate the invariants that the Actor model depends on, causing things to break erratically.
Request can be thought of as the big brother to ask. It wraps around ask, but handles the results inside the Actor's receive loop, so it can be used safely inside of an Actor. It even retains the value of sender, so you can easily handle cross-Actor calls in an intuitive way.
It's not quite boilerplate-free, but it's generally easy to use, much safer than ask, and results in relatively clean and intuitive code. Querki uses it quite heavily.
