As we’ve been adding skills to Optic (yes that’s the new name for Optic Knowledge), we’ve found ourself playing critical feature whack-a-mole. We definitely underestimated the number of critical use cases to get some of the everyday libraries and SDKs developers love supported. The good news is we’re just about there.
As reported last week we’ve already added support this month for:
Mutating transformations — transformations that change existing code. Supports things like “Add Action to Reducer” for Redux
Multi transformation — transform one kind of code into multiple other types of code. Supports transformations that need to write to multiple files.
This week we finished what we believe are the last core engines needed for a while:
Insert locations — allows you to create new files as part of a transformation.
Parser proxies — enables lenses to be created with otherwise invalid source code. For instance putting a Case statement in the top level of a code snippet won’t parse. Parser proxies allow parser authors to define a wrapper on a per AST Type basis to overcome this limitation. End users won’t have to think about these but they are important.
Multi Node Lenses — allows you to create a lens composed of n number of AST Nodes. User cases include creating a lens for Redux Containers. Each with a Component, PropTypes, MapStateToProps, Connect and Export node. Multi Node lenses behave like any other lens and can be synced.
Sublime support added. Ajay Patel from Plasticity finished the plugin. We’ll be packaging this in the next version of the installer.
This next release is already very big and contained a lot of risky features. It’s nearly ready to go but we’re going to delay it a little longer.
We want to switch our focus for the remainder of the summer from new features to building Optic’s repository of skills. To help with this task we feel like we have to make sure Optic Markdown 2 is part of this release.
Optic Markdown 2 is going to make it easier than ever to teach Optic new skills. It’s designed around the premise that Training > Explaining. Right now Optic Markdown is very verbose and requires users to fully grasp our system before they can make anything useful. V2 deploys some of the code pattern matching tech that makes Optic work to that training process.
In v1 users created lenses by giving a example snippet and then defining extractors to read/write certain properties of from that code. In v2 you provide a sample snippet and the expected JSON model to describe the code. Optic will search sample space and figure out how to round trip the code. If there are ambiguities that need resolution Optic will ask questions to resolve them and advanced users will still be able to override Optic’s decisions when needed.
It’s really cool and I’ve already seen some first time Optic users take advantage of the system without any coaching.