Summary
As the Holochain project matures, we continue to clarify the distinction between components. This is showing up in our testing framework and installation process, as well as the Git repos that hold them. As a result, our automated testing has been greatly simplified, giving us more time to work on new features!
This week we have some bug fixes, API improvements, and an entirely new way of defining a zome. We’re excited about these changes because they will make your life easier.
Highlights
1. Testing/Architecture: Node.JS Conductor Dropped from Tests
2. Installation/Architecture: Holochain Nix Moved to Own Repo
3. API (Breaking Change): Regex Matching on Link Tags and Types
4. API (Breaking Change): Cross-Zome Call and Bridged Zome Call Results More Consistent
5. API (Bug fixes): BadCallError Fixed and No Return DNA Entry in hdk::query()
6. API: Sneak Peek of New Zome Definition Macros!
Details
1. Testing/Architecture: Node.JS Conductor Dropped from Tests (#1475)
Two weeks ago, we talked about our new approach to DNA testing. We announced plans to drop the Node.JS conductor and rely on the actual, real-life Holochain conductor for testing. We’ve now completely dropped any dependency on the Node.JS conductor in our internal ‘app spec’ tests.
Why are we doing this and why should you care?
- When you run tests, they’ll live in the Holochain conductor itself, not a mock conductor. Your test results will more closely match real-world behavior.
- There are fewer dependencies for our dev tools installer, build environment, and HoloPort OS without a Node.JS library in the core repo. A big win for simplicity!
- Full integration testing of nodes including networking/n3h will be possible in the future. We don’t have this yet in the app-spec tests because all instances run on one conductor, which makes sense in some cases for speed, but it’s the next step toward running full production, equivalent p2p networks as regression tests for any changes to Holochain Core!
- We want our testing framework eventually to let us accept your DNAs and incorporate them into our test suite via an API. That would mean we could get advance warning if our changes break things that are already enjoying wide use in the real world. There will be more on this effort in future Dev Pulses.
What do you need to know about this change?
- The Node.JS conductor will live in its own repo and be removed from the main repo as early as next week. If you still want to use it, you can get it from NPM.
- Our new testing framework, Diorama, is available from NPM. You can use it in your own projects right away. (Note: When we introduced it in Dev Pulse 31, we called it hc-playbook.)
- The documentation for Diorama is coming soon. In the meantime, if you want to start using it, check out how our own tests have changed. You’ll note that most things are the same.
- Diorama tests are run using `npm test` rather than `hc test.`
- Our scaffolding tool, `hc generate` still creates boilerplate code for the Node.JS conductor — we’ll be updating it soon.
- As mentioned previously, if you’d like to take on maintenance of the Node.JS conductor, please talk to us on Mattermost. We’re committed to supporting you through the handover process and beyond.
2. Installation/Architecture: Holochain Nix Moved to Own Repo (#1501)
As you might know, we’re using nix-shell for our installer, which sets up a complete development environment for you with all the right dependencies — the Rust compiler and WebAssembly toolchain, the required libraries — the works.
3. API (Breaking Change): Regex Matching on Link Tags and Types (#1453)
A mere three weeks ago, we introduced a new feature for links called ‘tags.’ They let you add arbitrary content to your links, which is useful for filtering, simple indexing, fast pre-retrieval of entry data without having to load the entry itself, and more.
It’s such an exciting feature that we’ve already broken it by modifying the `get_links()` function. Previously, `get_links()` accepted an optional link type and tag, only returning exact matches.
Now you can specify regex matches for either of them, which lets you be more creative with your tag content and querying.
4. API (Breaking Change): Cross-Zome Call and Bridged Zome Call Results More Consistent (#1487)
Zomes and DNAs are the two basic building blocks for modularity in a Holochain app. A zome is a self-contained module of functions and data schemas; a collection of zomes makes a DNA.
Each DNA enjoys its own private network of participants, but if a user is running two DNAs, they can bridge between them so they can call each other’s functions.
You access a zome function in a bridged DNA the same way you would access a function in another zome within the same DNA — by using the `hdk::call()` function. Previously, however, the return value was different between the two uses. In one case, it would assume that all functions returned a Result and try to unwrap the value, which caused inconsistency. If a function didn’t return a Result, it would even throw an error. Now, you’ll always receive exactly what the function returns.
Note: This is a breaking change that we did not mention last week.
5. API (Bug fixes): BadCallError Fixed and No Return DNA Entry in hdk::query() (#1366 and #1490)
We made two bug fixes:
- You can now access globals, such as the DNA properties and agent ID, within your validation functions and receive callbacks. This fixes a bug that caused you to get a `BadCallError` if you attempted it. (Note: This bug fix landed in the previous release, but was missed in last week’s Dev Pulse.)
- `hdk::query()` no longer returns the content of the first source chain entry containing the DNA itself. Because the DNA can be quite large, it was causing `query()` to overwhelm the memory of the WebAssembly runtime.
6. API: Sneak Peek of New Zome Definition Macros! (#1326)
When we first introduced our zome development HDK to the world, we intended it to be a developer-friendly wrapper around the low-level core API. We found that it was certainly more usable, but still not where we wanted it to be. We’ve always wanted to improve it, but found ourselves restricted by the Rust language.
Rust has come a long way since then, which means that we’re able to do new things in the HDK.
We merged a new way of defining zomes, but it’s not quite ready for prime time yet. There are still a few features to be built before it’ll feel comfortable for you to use — but we want you to get excited, so here’s what we’ve been working on.
There have been many iterations, which we feel will make for much simpler, more readable zome definitions. For a sneak peek, browse through the source code of an imaginary app that uses this new HDK!
Development Status:
- 0.0.20-alpha3 Released
- Next: 0.0.21-alpha1
