Summary
We’ve made several feature enhancements in the 0.0.21-alpha1 release, building on the improvements we’ve recently made, and setting us up for even bigger achievements in the future. As part of our broader shift away from Node.JS, our scaffolding testing tools now run on Diorama. We’ve also made the detection of deleted links possible in chat apps, and simplified generating and reusing code (via crates).
Please note that 0.0.21-alpha1 was released on Wednesday 6/26. We noted previously that key items in that release would be mentioned in Dev Pulse 35.
See the Changelog for complete details.
Highlights
1. Breaking Change: Diorama for Scaffold Tests
2. MVP Implementation of Signals Adds Automatic Refresh to Chat Apps
3. ‘get_links’ Updated to Allow Status Requests on Deleted Links
4. Procedural Macro Option for hc generate
5. Breaking Changes: Persistence Crates and Serialization Crates Are Available
Details
1. Breaking Change: Diorama for Scaffold Tests (#1532)
We mentioned previously that we are moving to Diorama for our app-spec tests and dropping support for the Node.JS conductor. We’re updating two of the tools used to create scaffolding — the barebones working systems used during the testing process — as part of that transition. These tools, hc init and hc generate, also now run on Diorama.
All of the benefits of dropping Node.JS mentioned in the previous Dev Pulse — fewer dependencies, a true-to-life picture of how your apps will run — are now also available when generating tests in scaffolding.
2. MVP Implementation of Signals Adds Automatic Refresh to Chat Apps (#1516)
If you are notified with a zome code with an emit signal or a ‘receive call back,’ you can push the signal to the UI over the WebSocket channel. This means that the UI for the app will refresh automatically without users needing to manually reload to see new messages. Developers can now create hApps that feel as alive and responsive as people have come to expect from modern web apps. This is one of the most exciting developments from an app dev perspective in many months!
This change is only a first step; you’ll need to manually set it up to be notified in your node. But once you do, we think you’ll see the usability of your hApps go to the next level.
It’s important to remember that the implementation of Signals is a MVP; it doesn’t have all the checks and DNA definitions that we were hinting at in the Signals ADR. Our team will continue to make this implementation more robust and enable Holochain Basic Chat to receive response feedback.
3. ‘get_links’ Updated to Allow Status Requests on Deleted Links (#1337)
Fresh on the heels of the 0.0.20-alpha3 release, we have another update to the `get_links` function. If you’ve used it, you know that you only get links that are live or created, not deleted. With this update, you’ll now be provided with a status update if a link has been deleted.
This change was a long time coming — it was made possible by a recent merge on the pull request for the tombstone item.
A lot of effort went into addressing this — we were finally able to condense how the tombstone was implemented into something understandable. As a result, CRUD information can be retrieved from the link type, which we can query based on LinkStatusRequestKind.
4. Procedural Macro Option for hc generate (#1511)
One of our key goals is usability, particularly when it comes to writing code. To this end, we’ve added a new option to our hc generate tool — you can now generate a zome using the procedural macro in the HDK, replacing the old define_zome! macro. This should make it easier to write usable code templates when first generating a zome on start-up.
5. Breaking Changes: Persistence Crates and Serialization Crates Are Available (#1505 & #1551)
It’s natural in a project like ours to create very general bits of code in the course of our normal work. It then becomes clear that we may want to use those chunks of code in other parts of the system. Because we develop Holochain Core in Rust, we make code reusable through crates, which can be used by other teams or in other tasks. These crates do not have to be directly managed by the core team; in effect, they are their own mini-projects. At the same time, these bits of code become a dependency of abstract parts, yet still connected to the core system.
We have done this with two (related) updates. One incorporates persistence crates and serialization crates from Holochain Core and makes them available through the lib3h repo. The other fixes unmodified references to core_types_derive and related imports. These functions were both used by various parts of the code base and have now been moved into their own repositories to make it easier to be used by the networking component, as well as Holochain Core.
These functions were both used by various parts of the code base and have now been moved into their own repositories to make it easier to be used by the networking component, as well as Holochain Core.
These updates will be beneficial for the long-term sustainability of the project components and code. By moving this code into their own repos, they can be reused by others — not just in the Holochain community, but in the broader Rust ecosystem.
Our persistence library, for example, can be used by others who are able to do content-addressable stores. We are excited to adopt Rust ecosystem standards, like using the package manager crates.io for some of our packages — even the Holochain main libraries. If it happens, it’ll be a big step toward an aspirational goal considered part of the Holochain roadmap.
Moving in this direction is not without some pain, mostly internally. It is undeniably harder to develop something on two repositories at the same time. These challenges are one of the reasons we did not address the reorganization of the code before. We have repeatedly debated whether the time was now, but the benefits involved convinced us to go ahead and start down this path.
Documentation for Breaking Change #1505
Development Status:
- 0.0.21-alpha1 Released
- Next: 0.0.22-alpha1
