Add support for template variables #5

nishantwrp · 2021-07-14T19:45:06Z

No description provided.

nishantwrp · 2021-07-15T05:41:45Z

src/views/templateVariables.ts

+            `
+            <div class="variableInput">
+                <div class="variableName">
+                    ${variable}


Just remembered, I need to use encode from html-entities here too.

CalebJohn · 2021-07-18T21:34:48Z

src/index.ts

+                    const parsedTemplate = await parser.parseTemplate(template.body);
+                    if (parsedTemplate) {
+                        await joplin.commands.execute("newTodo", parsedTemplate);
+                    }


I said this before, but when you have identical code duplicated across 5 different places in the codebase, it's probably time to move it in to a function.

Yup, got it. Actually, at that time there were only 2 places of repetition, but now this definitely can be refactored. Thanks for pointing it out.

laurent22 · 2021-07-20T17:35:25Z

src/views/templateVariables.ts

+        );
+    }
+
+    return `<div class="invalidVariable"><i>${variable} has an invalid type.</i></div>`;


Missing encode()?

Yes, thanks for pointing it out.

laurent22 · 2021-07-20T17:37:03Z

src/views/templateVariables.ts

+        `
+        <h2> Template variables </h2>
+        <form name="variables">
+            ${variablesFormInputHtml.join("<br />")}


I don't think the <br/> are necessary? Since you are giving class names to your variable html, you could add the gap with CSS, which would make for cleaner HTML code.

Got it, will try without <br/>.

laurent22 · 2021-07-23T10:41:36Z

src/parser.ts

-    public async parseTemplate(template: string): Promise<string> {
+    public async parseTemplate(template: string | null): Promise<string | null> {
+        if (!template) {
+            return null;


Is there any reason why the template should be null in this case and not just an empty string? If you just make it an empty string I guess the rest of you code should work, shouldn't it? And then you won't need to have null checks and template: string | null in all the function definitions.

template could be null in a scenario where the user cancels the template selection dialog. That function supports getting different properties of the note like id, body, title etc., I am also planning to support getting complete note object using that function. So, returning an empty string there wrong to me.

Talking about string | null type, If I replace all of these with string. The plugin would still build successfully. I just added string | null so that the developer would know that receiving a null value is possible.

What do you think?

I'm talking about the current version of the function. If you plan to modify it later on, then you'll change the types, input and so on and that's a different topic. For now, as it is, I don't think the function is right.

In your code you are not doing any null check as far as I can see, so you're essentially treating the output of this function as string, not string | null, yet you return null. So again my question is: if you change it to return an empty string, would your code still work? I think it would, and that way you can get rid of the unnecessary string | null.

In general, you should avoid making special cases as it means you'll need to add conditionals to all the code that deal with the output of this function. So if you make it consistently return a string instead, the rest of the code is likely to be simpler too.

Oh okay, got it. I actually misunderstood earlier. Done!

nishantwrp · 2021-07-23T19:14:50Z

@laurent22 @CalebJohn this pr is ready for review.

CalebJohn · 2021-07-26T04:18:58Z

src/views/templateVariables.ts

+        );
+    }
+
+    if (type.startsWith("enum(") && type.endsWith(")")) {


I wonder if it makes more sense to use the yaml list syntax for this? I think this will affect how your parser works, but should be a lot better for users. For example
This

fruit: enum(apple, orange, banana)

Would become this

fruit: - apple - orange - banana

This isn't a requirement for this pull request, but it's something you should think about and perhaps bring to the community.

Hmm, in terms of implementation I don't think it's hard to implement. But the way the feature is currently implemented it will create some inconsistency in case we want to add more type of variables in future.

In terms of UX, I want to understand the reason you said

but should be a lot better for users

Because according to me, the users will have to do an equal amount of work in both cases they will have to look to the plugin documentation to see how should they declare enum template variables since it's not a standard.

But, I agree on the fact that as it's something like a list it seems more semantically correct to declare the options in the list syntax.

What do you think?

Actually, I have another idea. Let's create an issue to keep track of this. And in the future, we can support both these syntaxes.

What do you think?

My worry is that most users have never heard of an enum, so it's nonsense to them. But a list will make sense to them.

Tracking this in a seperate issue is a good idea, I'm looking forward to hearing your ideas.

Ah, okay. Got it, I always forget that a large fraction of Joplin users are non-programmers and enum is kind of a technical word. Sure, will create an issue for this.

CalebJohn · 2021-07-26T04:38:37Z

src/parser.ts

+            return compiledTemplate(context);
+        } catch (err) {
+            console.error("Error in parsing template.", err);
+            await joplin.views.dialogs.showMessageBox("There was some error parsing this template.");


Try to make this something actionable for the user. For example

"There was an error parsing this template, please review it and try again."

feat: add template variables feature

dc835d2

nishantwrp marked this pull request as draft July 14, 2021 19:45

nishantwrp commented Jul 15, 2021

View reviewed changes

nishantwrp added 2 commits July 18, 2021 19:08

feat: allow cancelling while taking variable inputs

99d10a2

fix: encode text in html

ff2bc1f

CalebJohn reviewed Jul 18, 2021

View reviewed changes

laurent22 reviewed Jul 20, 2021

View reviewed changes

nishantwrp added 2 commits July 23, 2021 02:25

feat: minor ui improvements

a56206a

refactor: create utility functions for redundant tasks

1a8e0f4

laurent22 reviewed Jul 23, 2021

View reviewed changes

feat: display template name in variable input dialog

5612f36

nishantwrp marked this pull request as ready for review July 23, 2021 19:14

nishantwrp requested review from CalebJohn and laurent22 July 23, 2021 19:14

refactor: return empty string

7fa787c

laurent22 approved these changes Jul 25, 2021

View reviewed changes

CalebJohn reviewed Jul 26, 2021

View reviewed changes

refactor: update error message when tempalte can't be parsed

56a109e

CalebJohn approved these changes Jul 26, 2021

View reviewed changes

CalebJohn merged commit c290b78 into master Jul 26, 2021

nishantwrp mentioned this pull request Jul 26, 2021

Support list syntax for enum type variables #7

Closed

nishantwrp deleted the template-variables branch July 27, 2021 10:32

Uh oh!

Add support for template variables #5

Add support for template variables #5

Uh oh!

Conversation

nishantwrp commented Jul 14, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nishantwrp Jul 23, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nishantwrp commented Jul 23, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

nishantwrp Jul 23, 2021 •

edited

Loading