Experimental loaders for the enojs library
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.



Experimental loaders for the enojs library


npm install enojs-exploaders

Currently available loaders

These loaders are currently available in the experimental track:

  • enum (generate the loader with enumFactory(choices), the returned loader accepts any of choices, returns the value unaltered or throws an error)
  • htmlEscaped (encodes & < > " ' / in the input as html entities, so you can e.g. insert the obtained string into HTML output without possible side effects)
  • slug (accepts only strings using the 0-9A-Za-z_- set of characters)


You can use the loaders with enojs as demonstrated in this example.

const eno = require('enojs');
const { enumFactory, htmlEscaped, slug } = require('enojs-exploaders');

const doc = eno.parse(`
  good-slug: the-article
  bad-slug: The Article!
  html: <script>alert("boom");</script>
  good-choice: sunscreen
  bad-choice: motor oil

doc.field('good-slug', slug);
  // returns 'the-article'

doc.field('bad-slug', slug);
  // throws an error "'bad-slug' must be a slug" through enojs

doc.field('html', htmlEscaped);
  // returns '&lt;script&gt;alert(&quot;boom&quot;);&lt;&#x2F;script&gt;'
const beachItem = enumFactory(['beach ball', 'sunscreen', 'shovel']);  
doc.field('good-choice', beachItem);
  // returns 'sunscreen'

doc.field('bad-choice', beachItem);
  // throws an error: 'bad-choice' must be one of 'beach ball', 'sunscreen', 'shovel'.


Trying out new, innovative, cool and stupid loader ideas and seeing how they fit into real life usecases. Based on the findings they might be repackaged, integrated into the enojs core, or who knows what!

Questions to explored

Core loaders

Are there more loaders not yet thought of that are so essential that they should be bundled up with the enojs library itself?


There could be a considerable amount of useful loaders, which all will require one or multiple error messages each - how can the translations for this be managed, versioned, updated, etc.?

From the insights gained with the core eno libraries it is safe to say that if there is to be some form of a shared translation repository, it should probably be shared by all (exp)loaders packages across different programming languages.


How should the loaders be categorized? Types (numbers, strings, ...)? Fields (IT, Communication, Geography)? Countries (International, country specific)?


How are the loaders imported, accessed and used in applications?


What kinds of loaders are actually sensible and useful to bundle for everyone, and where do we reach the limit of including too much bloat?