feat: Use mustachex engine for improving usability about mason HOT 14 CLOSED

Hello @felangel
If I may say my opnion I agree with @Rodsevich simplifying the syntax can have a great outcome
I'm working with mason and created a lot of bricks and it's really hard to work with a file with many variables, and it's hell to debug
simplifying
import 'package:{{#snakeCase}}{{app}}{{/snakeCase}}/{{#snakeCase}}{{feature}}{{/snakeCase}}/data/model/parameter/mock/{{#snakeCase}}{{name}}_mock{{/snakeCase}}.dart';
to
import 'package:{{app_sc}}/{{feature_sc}}/data/model/parameter/mock/{{name_sc}}_mock.dart';
I think worth it

and converting from this

to this

when I make a mistake in a file like this

it becomes a hell to debug the option to reduce the keystrokes by more than 60% is really appealing

from mason.

No problem for the delay, mate. My opinion is that, if it was a replacement of the original mustache spec I would be with you, of course; but as it's an extension the ones that work with regular mustache would have all the required to do so (the documentation and the engine), and those more pragmatic ones would have the feature for improving:

• the code writing time ({{varName_pc}}: 12 keystrokes {{#pascalCase}}{{varName}}{{/pascalCase}}: 42 keystrokes)
• the code legibility (just a reminder that {{varName_pc}} is only a shorthand of {{varName_pascalCase}})
• the intuitiveness (remember #53 and it's precedent related issues)
• the ease of use (you won't have to make complex dirs with kilometric names)
• more facilities for development (like {{#hasFoo}}{{/hasFoo}} guards)
• and much more (with the use of mason, new needs will be discovered and I will make more features like this one, which were born by the same origin)

Finally, I'm thinking about the nature of mustache, it's a good template engine thought for HTML that we are using for similar but different needs, situations like this normally remind me the 5 monkeys experiment and make me rethink several things.

from mason.

It took me some more time due to some issues now solved, it's now uploaded a NNBD 0.1.0 version

from mason.

Hi @Rodsevich 👋
Thanks for opening an issue and sorry for the delayed response! I really appreciate you bringing this up but for now I personally prefer to stick to the official mustache spec (or as close as possible) in order to enable developers to leverage existing knowledge of the templating syntax and to avoid having to maintain separate sets of documentation regarding the templating syntax etc. I'm happy to revisit this in the future as the project matures a bit more but at least for now I prefer to hold off and keep it as standard as possible. Let me know what you think and thanks again for reaching out! 🙏

from mason.

The migration to NNBD is almost done, actually. I'm uploading the new version this weekend surely.

from mason.

Just wanted to leave a few thoughts on this thread

1. The use of / in filenames is problematic. Does it work? Yes. But the file names are ugly and it makes git diffs look really weird. It requires explanation and time invested to understand and troubleshoot, then you have to document the behavior. This behavior is confusing to most people

2. I'm not convinced that Mustache is ubiquitous enough to be 'the standard.' There are so many other templating engines like nunjucks, liquid, etc. Mustache does not have a monopoly on templating for developers

3. A second templating engine can be added to mason, optionally deprecating Mustache. Fixing this issue does not have to be a breaking change

4. Mason could implement a few opinionated shortcuts with a new syntax to alleviate the folder/file name issue. If I were going to spike this, it would be piped {{name|snakeCase}}. I would nominate this list to implement in this way. We can alleviate the problem with small fixes

from mason.

Just wanted to leave a few thoughts on this thread

1. The use of / in filenames is problematic. Does it work? Yes. But the file names are ugly and it makes git diffs look really weird. It requires explanation and time invested to understand and troubleshoot, then you have to document the behavior. This behavior is confusing to most people

2. I'm not convinced that Mustache is ubiquitous enough to be 'the standard.' There are so many other templating engines like nunjucks, liquid, etc. Mustache does not have a monopoly on templating for developers
3. A second templating engine can be added to mason, optionally deprecating Mustache. Fixing this issue does not have to be a breaking change
4. Mason could implement a few opinionated shortcuts with a new syntax to alleviate the folder/file name issue. If I were going to spike this, it would be piped {{name|snakeCase}}. I would nominate this list to implement in this way. We can alleviate the problem with small fixes

Thanks for the feedback and I totally agree with most points. The only thing I’d challenge is the piped syntax since apparently pipes are not considered safe to use in file names.

The following are reserved characters:
< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)

Would love your thoughts on #183 and thanks again for the input!

from mason.

I just pushed up a PR, feel free to change the pipe character or request any changes #237. The parens suggestion in #183 also looks good to me

from mason.

@Rodsevich thanks for sharing! I think we can leave this open to gather feedback from the larger community. Do you have a timeline for when you plan to migrate mustachex to null safety?

from mason.

As the "feedback is wanted" tag is added I'll give my opinion about it.

As far as I am concerned, the decision to include a dependency on mustachex mainly depends on improving the lambda expression syntax.

I usually dislike the idea of introducing dependencies. Unless there is a highly valid reason to include it. If so, I think we should ensure the dependency will not hinder the development during any stage. Ensuring so can be complex.

Although I haven't had a closer look at mustachex it seems to me that mustache_template is somewhat more mature and popular. This doesn't mean mustachex is a bad package, it simply can mean that it has received less user feedback from the community.

Nevertheless, I think instead of focusing the discussion on "use mustachex" it should be on "improving usability".

I'm not sure if the syntax proposed by @Rodsevich is optimal. For example, with the provided syntax suggestion in the case that developers wished to have multiple formatted variables, the suggested syntax could, in some scenarios, be more redundant:

• {{#upperCase}}{{variable1}}{{variable2}}{{variable3}}{{/upperCase}}
• {{variable1_uc}}{{variable2_uc}}{{variable3_uc}}

But still, the suggested syntax is less verbose. Although, I dislike the idea of using abbreviations.

In addition, I agree with @felangel , this syntax is out of the standard and this results in developers being unable to leverage existing standards. But perhaps there are other standards one could adapt. I think we could take good inspiration from Blade Templates, not only for variables but also for if statements and more.

However, I agree with the disadvantages of @Rodsevich . More specifically, the current syntax is too verbose. This not only takes more time to write and is less human-readable but it may cause issues on some systems where there is a maximum path length.

In addition, as issues, #56 and #59 may point out. Some systems interpret the \ as a new directory and might end up with unexpected results. For example, when typing the name in VSCODE as in here the formatting is weird.

The question is, are we open and willing to improve the current lambda syntax even if it is outside of the mustache template syntax? I think this is vital and could potentially determine the success of mason over other templating tools. I say so because it reminds me of how JSON took popularity over XML, SOAP, etc. mainly by being more human-readable.

In conclusion, I believe using mustachex is not an optimal solution and I'm sceptical about including a dependency on mustcahex for the time being. However, I do think the current lambda syntax has major disadvantages and we should try to simplify it by taking inspiration from existing and popular templating syntax that have received valuable user feedback.

from mason.

I just pushed up a PR, feel free to change the pipe character or request any changes #237. The parens suggestion in #183 also looks good to me

Thanks will take a look!

from mason.

I agree that the {{#case}}{{var}}{{case}} is a pain to write.

I think {{var|case}} is already way better.

What do you think about using implicit cases for variables?
Var name should be case insensitive and output case is determined based on case type you've used to reference the variable:
given variable myVar: "myVarValue"
{{myVar}} => "myVarValue"
{{MyVar}} => "MyVarValue"
{{my_var}} => "my_var_value"
{{my-var}} => "my-var-value"

What are your thoughts on this?

from mason.

@Pierre2tm wouldn't that force you to have 2+ words variables names?
How would you command some name = 'pierre rodsevich' to be rendered as 'Pierre Rodsevich' somewhere, 'pierre_rodsevich' in another place and 'pierre-rodsevich' somewhere else?

from mason.

Rodsevich My bad you're right. That's not a good idea 😅.

from mason.