-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple instances of jsep with different operators #211
Comments
@EricSmekens and @LeaVerou - any thoughts on this? I know when we first started moving into a plugin system, this was discussed, but then dropped to reduce complexity/scope. I feel like this could be useful in some cases and could be re-done similar to what this commit removed? |
Any proposal for additional complexity should be justified through use cases. What are the use cases for having multiple parsers with different configurations and how common are they? |
@LeaVerou I would like to use jsep in a library with a custom binary operator but I cannot because of the singleton nature of it might lead to transient, hard to locate bugs |
I think what @joeflateau said sums it up for me. I was considering using this for an application, where I would want to be able to parse boolean expressions and number expressions separately under different rules. While I could manage with this singleton, it would require swapping out the acceptable operators and things each time I want to parse an expression, which is rather wasteful. |
related to #28 |
Before this change, JSEP `parse` was constructing a new instance of the JSEP class to encapsulate the expression and index as it was parsed, and the JSEP configuration was static on the class. Since JSEP parsing is synchronous, separate calls to parse can safely reset the expression and index instead of creating a new instance. Doing so allows the configuration to be moved into the JSEP instance, so that separate configurations can be used for different jsep parsing usages. The `parse` method then resets the instance's expression and index rather than constructing a new instance. This allows JSEP to functionally maintain backward compatibility despite the structural change. This commit essentially adds `instance()` (with default `clearConfig()` setup), and `defaultConfig()` methods. All static accesses were replaced with `this`. Specific things to note: - JSEP still exports the parse function with the instance's properties and methods for configuration - all static methods and properties have been moved to the instance (even constants and methods that don't access instance properties, so they can still be used by plugins). To keep the static constants available on each instance without forcing users to now access the prototype, they get assigned in the constructor - the export is still the instance's parse function, with all methods and properties accessed through a Proxy (rather than copying all properties and binding all methods) - the Jsep class export is replaced with the jsep instance export so that `{ Jsep } = require('jsep')` still works as before (unless user was calling (new Jsep('expr')).parse()) - because the ternary plugin is included by default, it gets specially registered once, so that `defaultConfig` can include the default plugin as well - fix `removeAllBinaryOps` not clearing `right_associative` fixes #211 BREAKING: changes JSEP internals to be a class instance per config, rather than per parse. `Jsep` export is now the combined parse function & class instance instead of the Jsep class. so usages that were directly using the Jsep class (`new Jsep(expression)`) will have update to either `Jsep(expression)` or `Jsep.parse(expression)`. Most applications should be backward compatible without any changes to code
Hi guys.
There is any reason to have a singleton parser? There is no chance to have more than one jsep with different configuration running in the same app at client side?
Thank you,
Carlos Marcão
The text was updated successfully, but these errors were encountered: