Snowman 2.2 Development Updates:
- Snowman Dev Update (2.2: May 2022)
- Snowman Dev Update (2.2: 5 June 2022)
- Snowman Dev Update (2.2: 12 June 2022)
- Snowman Dev Update (2.2: 14 June 2022)
- Snowman Dev Update (2.2: 19 June 2022)
- Snowman Dev Update (2.2: 26 June 2022)
- Snowman Dev Update (2.2: 3 July 2022)
Restricting Underscore and now using EJS for templates
For the last two weeks, none of the testing builds included Underscore.js. In deciding to embrace testing examples for the Twine Cookbook, I noticed a large number of examples not only explicitly mention Underscore.js, they also use its functionality. This has meant, in trying not to break too much from past examples, I have had to re-include it in Snowman builds.
In originally removing Underscore.js, I decided to switch the template functionality to EJS. This is what Snowman 2.2 now uses. All template functionality still works, but the code is no longer beholden to Underscore.js, a library which no longer seems to be used or updated as much as it was years ago.
Code sandboxes and pseudo-global properties
With the usage of the new runScript() method, new global-like properties can be added to story format without also adding multiple properties to the window global. While more testing is definitely needed, I really prefer this approach to allowing authors to use functionality without also polluting global properties.
No more passage rendering
In previous versions of Snowman, the Passage class contained a render() method. This was called when the content (source) of the passage was needed and would run the content through a rendering process. Nearly always, this was in result from a call from the global object Story and its own render() method. From the point of view of a component-based system such as React, this makes perfect sense. Every component takes care of itself. It holds internal state data and possible interactions. However, in Snowman, this is not true. Passages only hold data. There are no direct interactions that do not pass through the story-interaction layer.
Part of this change came about when thinking through how to use the Story.runScript() method. The more I thought through how the previous Passage.render() method was supposed to work, the more I realized it was not needed. The processing of any data takes place as a result of an author interacting with the story, which means only the Story class should be processing passage data.