Dojo has long distinguished itself with a robust and complete application architecture. And the foundation of this architecture has been the store interface, providing clean separation and consistent interface between presentation and data sources. We are committed to continuing to improve this architecture, and in this pursuit, we now releasing dstore, a next generation object store interface and set of data modeling components.
dstore is an exciting new package that provides a number of significant improvements over the prior data store framework, including a more fluent querying API, improved event notification, advanced cross-store filtering, and a more modular mixin system that allows us to easily combine components with alternate format support, advanced querying support, and more. In this post, we want take a brief look at these new features and improvements. From there, you can explore the tutorials and documentation that we have written for this new package.
At many conferences, the hallway track is more interesting than the track during presentations. It’s the serendipity of a small group of people interested in solving a similar problem that run into each other and just start talking through it that makes the hallway track the most interactive experience at most conferences.
EdgeConf capitalizes on these discussions by turning the hallway track into what the conference is all about! There are a selected set of topics covering emerging trends in web technologies and a panel of 5-6 people take the stage with one stepping forward to bring the audience quickly up to speed. The discussion begins!
The panelists work through a set of curated questions and there’s a system for the audience to participate and join the debate. Everyone is encouraged to spend less than a minute at a time talking, ideally 30 seconds or less. If the speaker goes over 2 minutes, there’s a nice warning across the screen on stage that tells the speaker that their time’s up. Oh, and the whole thing was streamed live! You can watch all 10 hours of coverage or read the gist below!
Today we’re happy to announce the release of Intern 2.1. This release contains several bugfixes and improvements to existing functionality, as well as new features to make running tests and handling test results easier. The full list of enhancements and bugfixes is available in the release notes. Here are some of the highlights!
More output options
Two new reporters have been added to Intern: an HTML reporter for the browser client and a JUnit XML reporter.
The HTML reporter is a new default reporter for Intern’s browser client runner (
client.html). It displays at the end of a test run, summarizing the test results and presenting them in an easy-to-read format:
The output of the JUnit reporter, on the other hand, is meant for machine consumption. It aggregates test results and outputs them in a
report.xml file that follows generally accepted standards for JUnit-compatible XML. This makes it much easier to plug Intern into tools that accept JUnit reports, like Jenkins.
While TypeScript is very simple to understand when performing basic tasks, having a deeper understanding of how its type system works is critical to unlocking advanced language functionality. Once we know more about how TypeScript really works, we can leverage this knowledge to write cleaner, well-organised code.
If you find yourself having trouble with some of the concepts discussed in this article, try reading through the Definitive Guide to TypeScript first to make sure you’ve got a solid understanding of all the basics.
When developing for the web, it is a recommended best practice to always test your application during development with a web server. This is for two primary reasons. By running a web server, you can approximate a production environment similar to how your application will be served to your users. Also, browsers implement a same-origin policy that is different for quasi-protocols like
file://. Many of Dojo’s modules like
dojo/text, Dijit templates, and
dojox/gfx depend on loading files from the same origin.
A common practice when adding new elements to a document is to add them to a container DIV and then insert that node into into a document. A lesser used alternative is the
DocumentFragment class. So, what is a document fragment, and when should you use one instead of a container DIV?
When writing tests for an application, it’s prudent to add mock or stub data in order to allow code to be properly tested in isolation from other parts of the system. Within a normal Dojo application, there are typically three places where mocking will occur: I/O requests, stores, and module dependencies.
Many of the best practices for writing testable code also conform to general code best practices. Code that is easily testable often also tends to be highly maintainable and resilient against changing business requirements. This blog post provides a brief overview of key criteria for writing highly testable code.
At SitePen, we have long been advocates for building web applications on a RESTful architecture. Over the last several years, it has been exciting to see organizations increasingly provide RESTful endpoints for the Dojo-based front-ends that we support and develop. A well-designed REST backend can be a excellent foundation for manageable, scalable applications, that will be ready to evolve into the future. I wanted to share a few tips for designing a set of RESTful services.