Is there a way to hook into PTT warnings

[rizen]

PTT puts warnings (like unclosed tags) into the console. Is there a way to hook into those so I could display them to the user?

[mimshwright]

There are two possible solutions:

• Rather than logging warnings, the library can throw an error. The errors can be caught by your app and handled. (by default we don't do this because it can end up making life harder for the users of the library and frankly there are a lot of people who don't know how to handle errors)

• you can override (hack) console.warn with a custom function that can receive the message and decide what to do with it.

Probably the best solution is to provide an optional setting for whether to throw errors or show console messages (or neither).

[mimshwright]

Maybe a third solution is to save the error state in code somewhere. Like taggedText.errors

[rizen]

Maybe another solution is to pass a warnings handler function into options and the default warnings handler is to console.warn() like you do now, but if I've passed one use that instead?

[mimshwright]

You could also have methods like validateTags() which could return a result for each type of issue. I guess there are many more than 2 possible solutions!

These are all pretty easy to add. Here's what I'd propose:

1. Your idea: an option for adding a callback/handler for any errors that receives an object with target, type, and description.
2. And an option for how to do warnings, either "off", "warn", "error" with default to "warn"

[rizen]

Sounds fine

[mimshwright]

@rizen
I've added this in version 3.3.0. You can provide a function that gets an object like { message:string, code:string, type:string }. There's also an option to supressConsole which disables console messages except for debugConsole messages.

Currently, there are only a handful of situations where you will receive one of these warnings, that is, any time when you would have gotten console.warn in the past. I am undecided on whether to expand to errors and wanted to get your opinion. It would require that I go through the codebase and reroute any code that normally would throw an error through this logger. Additionally, I'm not sure how best to handle all uncaught errors that might come up that not directly related to my code.

I hadn't given this topic a whole lot of thought in the past but there should probably be a rule like "if it only breaks the style, make it a warning not an error". For example, this code currently throws but probably should warn and use the default value "left":

throw new Error(
        `Unsupported alignment type ${align}! Use one of : "left", "right", "center", "justify"`
      );

[mimshwright]

Crap. I forgot to add the target to the errorMessage object. I expect you'll want that so you can identify which text field has the error. I'll add that.

Update: added in v3.3.1

[mimshwright]

Note to self, fix warnings on percentage font size