search

lephyrus / ngx-translate-messageformat-compiler

Advanced pluralization (and more) for ngx-translate, using standard ICU syntax which is compiled with the help of messageformat.js.
MIT License
93 stars 29 forks source link

Handle SyntaxError caused by property access syntax better #19

Closed pascallaprade closed 6 years ago

pascallaprade commented 6 years ago

While your documentation clearly states that You lose the ability to access object properties in your placeholders: 'Hello {name.first} {name.last}' won't work., the result of disregarding this rule is not obvious.

Indeed, by integrating this compiler to an already existing code-base, we missed a single occurrence of a property access syntax in one of our placeholder, during a git merge operation, and the resulting error was actually a raw exception caught in the catch handler of the bootstrapModule call made in our main.ts file.

Here is the exception I got: https://gist.github.com/pascallaprade/e5bced0d500dd2400166c5e725c2a3d8

You should capture this error and provide a prettier message to the user when the "no-property-access" rule is violated. Ideally, the error would point at the file, line and character where the rule was violated, spell out clearly the rule that is being violated, and should clearly state that the error is related to 'ngx-translate-messageformat-compiler', to help the user narrow down its search of the faulty syntax. Even better, the error message could suggest to the user how the problem could be fixed, i.e. by providing the desired property directly.

ClemensSchneider commented 6 years ago

I would pledge for a console-statement, too. I missed a {{, too and found my application no longer bootstrapping. Or maybe we could provide some kind of configuration option on how to treat parse-errors (throw error, log to console, provide custom error-handler).

lephyrus commented 6 years ago

Trying to implement your suggestions would increase the complexity of this library significantly. You may not realize this, but it doesn't really do much at all - look at the source code. To be honest, I don't think intercepting a parse error from messageformat and then figuring out where in the app the string came from is even possible without significant changes to ngx-translate/core.

In any case, even doing the research necessary is far more effort than I can and want to invest. PRs are welcome of course... :wink:

Having said that, I've just released v4.1.0 which includes TranslateMessageFormatDebugCompiler. It prints console log messages that should make it easier to figure out where a syntax error originates.