We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Hi, I'm super excited about this project, fun and interesting!
Of course I was playing around to make it work, so I tried to understand this:
superscript/src/plugins/user.js
Line 40 in 37f2be9
I wrote my own hasProp plugin which receives booleans perfectly, so it could be used as {^hasProp("name", false)} without issues:
hasProp
{^hasProp("name", false)}
function hasProp(prop, val, cb) { const memory = this.user.memory; const userId = this.user.id; memory.db.get({ subject: prop, predicate: userId }, (err, res) => { const value = res[0] && res[0].object; if (typeof value !== 'undefined' && value !== null) { cb(null, val === true); } else { cb(null, val === false); } }); }
I don't feel this consistent, unless you encourage us to use plugins as {^hasProp("name", "false")} which is bit weird imho.
{^hasProp("name", "false")}
The question is, why you used a string comparison instead?
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Hi, I'm super excited about this project, fun and interesting!
Of course I was playing around to make it work, so I tried to understand this:
superscript/src/plugins/user.js
Line 40 in 37f2be9
I wrote my own
hasProp
plugin which receives booleans perfectly, so it could be used as{^hasProp("name", false)}
without issues:I don't feel this consistent, unless you encourage us to use plugins as
{^hasProp("name", "false")}
which is bit weird imho.The question is, why you used a string comparison instead?
The text was updated successfully, but these errors were encountered: