eta Which line in the template causes the render error?

I'm coming from ejs where when there's a render error the error message looks something like this

    1|  <div>
 >> 2|    <%= notArray.map(x => x.name).join(", ") %>
    3|  </div>
    4|

notArray.map is not a function

but in eta the error message is just

notArray.map is not a function

It's not telling me which line in the template has the error, why?

May 06 '22 08:05 ahmedkamalio

Pardon me, but why is it important to know what line in the template has an error? It should be fairly easy to identify through which line it is referencing, since the variable notArray probably shouldn't be changing through out the template.

May 21 '22 19:05 shadowtime2000

@shadowtime2000 we are building a system that generates reports based on ejs/eta templates, each template has a ton of dynamic data and it's been pretty hard to determine where's the error coming from!

let me give you an example, but generally, templates are way longer than that:

<section>
  <p>The permitted use of each of the Leases is summarised in the following table.</p>
  <table>
      <head>
        <tr>
          <th>Lease</th>
          <th>Permitted use</th>
          <th>Description</th>
        </tr>
      </thead>
    <tbody>
    <% for (const lease of document.getById("some_id").value) { %>
      <tr>
        <td><%= document.getById("some_id").value %></td>
        <td><%= document.getById("some_id").value?.name %></td>
        <td><%= document.getById("some_id").value || "(Intentionally left blank)" %></td>
      </tr>
    <% } %>
    </tbody>
  </table>
</section>

and then you get an error that document.getById(...) is not iterable or is null etc. but you don't know which document.getById(...) call is causing that error until you iterate over all of them.

Hope my example makes sense!

May 21 '22 20:05 ahmedkamalio

Finally coming around to this, it seems EJS automatically puts in a lot of boilerplate code within compiled templates to allow the lines and line number to get attached to the error. To implement this in Eta we would need to add some sort of event to run during the compilation of an array of AST objects into a function string, that would allow us to surround every single string or function executed with a try {} catch {} to then rethrow it with formatting with the line numbers, and these line numbers would also need to be hard coded into the function.

This would most definitely either become a plugin, like eta_plugin_clean_errors, or a config option, maybe cleanErrors. To borrow from EJS, which seems to have the best solution around, we would need to create a simple function to attach to the beginning of a function when compiling a template, which will take an error, along with data like line text and line number, and then format it so it looks clean in the terminal. Every single time dynamic data is incorporated into the template in the compiled function, it would need to be wrapped with a try {} catch (e) {}, and in the catch use this formatting function to then reformat the error. Since the line number and line text is needed for the error, we would need the parse function to attach line number and line text into the AST, and then have the compileToString to hard code it into temporary variables that will change every time dynamic data is used again.

Jul 05 '22 08:07 shadowtime2000

This is enabled in Eta v3, when you pass in the debug: true config option :tada:

Jun 13 '23 20:06 nebrelbug

eta eta copied to clipboard

Which line in the template causes the render error?

eta
eta copied to clipboard