Skip to content
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

Open
cmarcao opened this issue Feb 7, 2022 · 5 comments · May be fixed by #272
Open

Multiple instances of jsep with different operators #211

cmarcao opened this issue Feb 7, 2022 · 5 comments · May be fixed by #272

Comments

@cmarcao
Copy link

cmarcao commented Feb 7, 2022

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

@6utt3rfly
Copy link
Collaborator

@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?

@LeaVerou
Copy link
Collaborator

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?

@joeflateau
Copy link

@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

@Julusian
Copy link

I think what @joeflateau said sums it up for me.
If writing an application, then the singleton nature most likely isnt an issue.
But if writing a library, it could be an issue if some other component of the application also uses jsep.

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.

@jdanyow
Copy link

jdanyow commented Jul 29, 2023

related to #28

6utt3rfly added a commit that referenced this issue Nov 18, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants