📢 HMPL v3.1: New major update!

#javascript #webdev #opensource #programming

We've finally finished one of the most long-awaited updates, which brings us a little closer to one of the best tools for creating HATEOAS apps in the world (we hope)!

We've done a lot of interesting things with it. Since the project hasn't had any code updates for a while, this is a breath of fresh air that will boost its usability.

Today, we'll be talking primarily about app security, keeping apps up to date, and more. So, let's get started!

🔏 Improving security

When working with Hypermedia, unlike other tools, we pay special attention to the security of incoming data from the server. Therefore, one of our solutions was integration with DOMPurify, which cleans incoming HTML of potentially dangerous markup.

<!-- 
Response before:
<script></script>
<div>My component</div>
-->
<div>
  {{#request
    src="/api/get-my-component"
    sanitize=true
  }}{{/request}}
</div>
<!-- 
Response afer:
<div>My component</div>
-->

However, the problem arose that with default sanitizing we get fairly predictable application behavior, which is generally safe, but not flexible. Therefore, we introduce the sanitizeConfig property.

/**
 Response before:
 <div></div><math></math>
*/
const templateFn = compile("...",{
  sanitize: true,
  sanitizeConfig: { USE_PROFILES: { html: true } }
});
/**
 Response after:
 <div></div>
*/

It's based on Config with DOMPurify and allows, for example, blocking MathML from the application, as well as a lot of other customizations. This makes the tool truly comprehensive, and it will process even the most bizarre responses as the developer originally intended, without any boilerplate.

This property has been added to compile and is not planned to be moved to block helpers.

⚙️ Changing arguments for the get function

This is one of the most controversial changes, in my opinion, and one we've been thinking about for a long time. It would seem that if there are more than two arguments, then the properties should be immediately converted to an object, but this proved difficult.

before:

const elementObj = templateFn({
  get: (prop, value, context, request) => {
   ...
  }
});

after:

const elementObj = templateFn({
  get: ({ prop, value, context, request }) => {
   ...
  }
});

It would seem that you almost always use only two arguments in get, but if we were to work with the same context, we'd have to represent the arguments as an array and access them by index. Alternatively, we could specify unused variable names, but then linters wouldn't allow this code, so we believe the approach we've implemented is better.

We would just like to know your opinion, did we do the right thing?

💬 Feedback

You can write your thoughts about the new features in the comments, it will be interesting to read! Or, there is a thematic Discord channel for questions and suggestions, there I or someone else will try to answer!