Comments (14)
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
- 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
-
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
-
A second templating engine can be added to mason, optionally deprecating Mustache. Fixing this issue does not have to be a breaking change
-
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
- 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![]()
- 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
- A second templating engine can be added to mason, optionally deprecating Mustache. Fixing this issue does not have to be a breaking change
- 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.
Related Issues (20)
- feat: support conditional prompting for variables HOT 6
- feat: include `prompt` style in `LogTheme`
- fix: Extra line with condition statement HOT 5
- feat: hook resource sharing
- perf: Generating files from a list which is not a simple string rather a List<Map<String, dynamic>> takes over 30 minutes HOT 2
- feat: simplify relying on defaults when using `mason make` in CI HOT 2
- fix: Generating files from array not working HOT 6
- fix: Crash with "StreamSink is bound to stream" HOT 5
- fix: mason_logger does not handle `stdin.hasTerminal` being false
- fix: The getter 'STD_HANDLE' isn't defined for the class 'WindowsTerminal'. HOT 8
- Failing to activate mason_cli after upgrading to mason_cli: ^0.1.0-dev.54 HOT 1
- feat: set default output directory HOT 3
- feat: ask to overwrite or not for duplicate brick name
- feat: Retain colors across process boundary HOT 2
- fix: `Isolate.spawnUri()` does not contain a valid AOT snapshot on script compiled with `dart compile exe` HOT 5
- feat: Mirror logger output to a file
- FileSystemException: Creation failed. (OS Error: File name too long, errno = 63) HOT 2
- fix: mason_logger is not working properly when it reaches to the end of terminal HOT 8
- fix: Brick.git not generating windows HOT 1
- I cannot publish my mason brick HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
š Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ššš
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ā¤ļø Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mason.