diff options
Diffstat (limited to 'book/src/main/scalatex/book/indepth')
5 files changed, 14 insertions, 12 deletions
diff --git a/book/src/main/scalatex/book/indepth/AdvancedTechniques.scalatex b/book/src/main/scalatex/book/indepth/AdvancedTechniques.scalatex index 171b2d3..98dccc2 100644 --- a/book/src/main/scalatex/book/indepth/AdvancedTechniques.scalatex +++ b/book/src/main/scalatex/book/indepth/AdvancedTechniques.scalatex @@ -76,7 +76,7 @@ Scalatags requires that anything you want to embed in a Scalatags fragment be implicitly convertible to @hl.scala{Frag}; here we are providing one for any Scala.Rx @hl.scala{Rx[T]}s, as long as the @hl.scala{T} provided is itself convertible to a @hl.scala{Frag}. We call @hl.scala{r().render} to extract the "current" value of the @hl.scala{Rx}, and then set up an @hl.scala{Obs} that watches the @hl.scala{Rx}, replacing the previous value with the current one every time its value changes. @p - Now that the set-up is out of the way, let's consider a simple HTML widhet that lets you enter text in a @hl.html{<textarea>}, and keeps track of the number of words, characters, and counts how long each word is. + Now that the set-up is out of the way, let's consider a simple HTML widget that lets you enter text in a @hl.html{<textarea>}, and keeps track of the number of words, characters, and counts how long each word is. @split @more @@ -177,13 +177,10 @@ @p Overall, these helper functions do nothing special, btu we're defining them first to avoid having to copy-&-paste code throughout the subsequent examples. Now that we've defined all the relevant scaffolding, let's walk through a few ways that we can implement the all-important @hl.scala{handle} method. - @def scrollDiv = div( - height:="200px", - overflow:="scroll" - ) + @def exampleDiv = div(height:="200px") @sect{Direct Use of XMLHttpRequest} - @example(scrollDiv, "Futures().main0") + @example(exampleDiv, "Futures().main0") @hl.ref("examples/demos/src/main/scala/advanced/Futures.scala", "def handle0", "main") @p @@ -195,7 +192,7 @@ This solution is basically equivalent to the initial code given in the @sect.ref{Raw Javascript} section of @sect.ref{Interactive Web Pages}, with the additional code necessary for aggregation. As described in @sect.ref{dom.extensions}, we can make use of the @hl.scala{Ajax} object to make it slightly tidier. @sect{Using dom.extensions.Ajax} - @example(scrollDiv, "Futures().main1") + @example(exampleDiv, "Futures().main1") @hl.ref("examples/demos/src/main/scala/advanced/Futures.scala", "def handle1", "main") @p @@ -204,7 +201,7 @@ However, we still have the messiness inherent in the result aggregation: we don't actually want to perform our action (writing to the @hl.scala{output} div) when one @hl.scala{Future} is complete, but only when @i{all} the @hl.scala{Future}s are complete. Thus we still need to do some amount of manual book-keeping in the @hl.scala{results} buffer. @sect{Future Combinators} - @example(scrollDiv, "Futures().main2") + @example(exampleDiv, "Futures().main2") @hl.ref("examples/demos/src/main/scala/advanced/Futures.scala", "def handle2", "main") @p @@ -287,14 +284,14 @@ @example(canvas, "Async().main") @p - We have an @hl.scala{async} block, which contains a while loop. Each round around the loop, we wait for the @hl.scala{mousedown} channel to start the path, waiting for either @hl.scala{mousedown} or @hl.scala{mousedown} (which continues the path or ends it respectively), fill the shape, and then wait for another @hl.scala{mousedown} before clearing the canvas and going again. + We have an @hl.scala{async} block, which contains a while loop. Each round around the loop, we wait for the @hl.scala{mousedown} channel to start the path, waiting for either @hl.scala{mousemove} or @hl.scala{mouseup} (which continues the path or ends it respectively), fill the shape, and then wait for another @hl.scala{mousedown} before clearing the canvas and going again. @p Hopefully you'd agree that this code is much simpler to read and understand than the previous version. In particular, the control-flow of the code goes from top to bottom in a "natural" fashion, rather than jumping around ad-hoc like in the previous callback-based design. @p You may be wondering what these @hl.scala{Channel} things are, and where they are coming from. Although these are not provided by Scala, they are pretty straightforward to define ourselves: - @hl.ref("examples/demos/src/main/scala/advanced/Async.scala", "case class Channel") + @hl.ref("examples/demos/src/main/scala/advanced/Async.scala", "class Channel") @p The point of @hl.scala{Channel} is to allow us to turn event-callbacks (like those provided by the DOM's @hl.scala{onmouseXXX} properties) into some kind of event-stream, that we can listen to asynchronously (via @hl.scala{apply} that returns a @hl.scala{Future}) or merge via @hl.scala{|}. This is a minimal implementation for what we need now, but it would be easy to provide more functionality (filter, map, etc.) as necessary. diff --git a/book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex b/book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex index 1718f5e..cb55bf9 100644 --- a/book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex +++ b/book/src/main/scalatex/book/indepth/CompilationPipeline.scalatex @@ -1,3 +1,4 @@ +@import BookData._ @p Scala.js is implemented as a compiler plugin in the Scala compiler. Despite this, the overall process looks very different from that of a normal Scala application. This is because Scala.js optimizes for the size of the compiled executable, which is something that Scala-JVM does not usually do. diff --git a/book/src/main/scalatex/book/indepth/DesignSpace.scalatex b/book/src/main/scalatex/book/indepth/DesignSpace.scalatex index a1e807f..f167ea6 100644 --- a/book/src/main/scalatex/book/indepth/DesignSpace.scalatex +++ b/book/src/main/scalatex/book/indepth/DesignSpace.scalatex @@ -1,3 +1,5 @@ +@import BookData._ + @p Scala.js is a relatively large project, and is the result of both an enormous amount of hard work as well as a number of decisions that craft what it's like to program in Scala.js today. Many of these decisions result in marked differences from the behavior of the same code running on the JVM. This chapter explores the reasoning and rationale behind these decisions. diff --git a/book/src/main/scalatex/book/indepth/JavaAPIs.scalatex b/book/src/main/scalatex/book/indepth/JavaAPIs.scalatex index 0ad886d..685fdfd 100644 --- a/book/src/main/scalatex/book/indepth/JavaAPIs.scalatex +++ b/book/src/main/scalatex/book/indepth/JavaAPIs.scalatex @@ -1,3 +1,5 @@ +@import BookData._ + @p Below is a list of classes from the Java Standard Library that are available from Scala.js. In general, much of @hl.scala{java.lang}, and parts of @hl.scala{java.io}, @hl.scala{java.util} and @hl.scala{java.net} have been ported over. This means that all these classes are available for use in Scala.js applications despite being part of the Java standard library. @p @@ -37,7 +39,7 @@ @p And other similar APIs will either need to be rewritten to not-use them. For example, @hl.scala{AtomicXXXs} can be written without threading/unsafe APIs because Javascript is single-threaded, making the implementation for e.g. an @hl.scala{AtomicBoolean} pretty trivial: - @hl.ref("output/scala-js/javalib/src/main/scala/java/util/concurrent/atomic/AtomicBoolean.scala") + @hl.ref(cloneRoot + "/scala-js/javalib/src/main/scala/java/util/concurrent/atomic/AtomicBoolean.scala") @p Others can't be ported at all (e.g. @code{java.io.File}) simply because the API capabilities they provide (blocking reads & writes to files) do not exist in the Javascript runtime. diff --git a/book/src/main/scalatex/book/indepth/SemanticDifferences.scalatex b/book/src/main/scalatex/book/indepth/SemanticDifferences.scalatex index ebfd1db..96f3929 100644 --- a/book/src/main/scalatex/book/indepth/SemanticDifferences.scalatex +++ b/book/src/main/scalatex/book/indepth/SemanticDifferences.scalatex @@ -1,6 +1,6 @@ @import BookData._ @p - Although Scala.js tries very hard to maintain compatibility with Scala-JVM, there are some parts where the two platforms differs. This can be roughly grouped into two things: differences in the libraries available,and differences in the language itself. This chapter will cover both of these facets. + Although Scala.js tries very hard to maintain compatibility with Scala-JVM, there are some parts where the two platforms differs. This can be roughly grouped into two things: differences in the libraries available, and differences in the language itself. This chapter will cover both of these facets. @sect{Language Differences} @sect{Floats are Doubles} |