Thanks for this helpful step-by-step code with familiar TodoMVC example. This makes it much easier for me to get familiar and play around with Marko new tags API 👍 I was surprised that you can't mix it with the old <if()>, or maybe I did something wrong with my code 😅
Anyhow, I have some questions.
On the example, you use Marko component for the TodoStore. Is it possible to replace TodoStore.marko with just JS? Not sure if you implement the store as a Marko component just for an example, or it's a must in order to make it work.
Another thing, how can we lint JS code inside Marko template, do we have eslint plugin for Marko? My impression with Marko Tags API that it seems we are putting more and more JS code inside the template. Without linting tool, it would be harder to know if there's syntax error on the code. It seems Marko compiler can catch some but maybe you know better tool to handle this problem.
Yeah mostly that since we are streamlining composability we are replacing the () (default arguments) with = (default attribute). In this way we can extend this capability out to custom tags you might author. Default attribute has some benefits in that it only accepts a single argument.
So <if(condition)> is now <if=condition>. How we handle backwards compatibility is still open but we wanted the preview to only contain future facing syntax to get a feeling for what the intended experience.
As for the store, you could do it with just JavaScript to a point. The unit of change, the equivalent to React's useState or Vue's ref or Svelte's let is Marko's <let> tag. So you could set and update that with JS from the outside but it wouldn't be granular. In the same way you need to update their core primitives you need to do so with Marko. So using the primitives in file makes it easier to make it more performant.
It's a bit of a departure but we have primitives for Context API, etc for more advanced patterns, and more interestingly is tags let you colocate in the markup. Nest data exactly where you need to use it without additional imports etc. Not saying you would but when Marko 6 comes along you could make a whole app in a single template with no performance degradation. Components no longer are a limiting factor.
In some ways it's like the diagram when React Hooks came out that showed how we reduced the interweaving of logic compared to class Components. This takes it even further. Basically single cut and paste refactoring. Almost like dealing with plain HTML.
That being said it only raises the bar on tooling in templates. And on this we agree. Work in the last year from Vue and Svelte have given us a pretty clear trajectory in getting TypeScript, Prettier, and ESLint support. Things that these custom DSLs have always struggled a bit with. So this is definitely something being worked on. But as you can imagine with something so big coming around the corner it didn't make the most sense to develop that out with these changes coming down the pipeline.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for this helpful step-by-step code with familiar TodoMVC example. This makes it much easier for me to get familiar and play around with Marko new tags API 👍 I was surprised that you can't mix it with the old
<if()>, or maybe I did something wrong with my code 😅Anyhow, I have some questions.
On the example, you use Marko component for the TodoStore. Is it possible to replace
TodoStore.markowith just JS? Not sure if you implement the store as a Marko component just for an example, or it's a must in order to make it work.Another thing, how can we lint JS code inside Marko template, do we have eslint plugin for Marko? My impression with Marko Tags API that it seems we are putting more and more JS code inside the template. Without linting tool, it would be harder to know if there's syntax error on the code. It seems Marko compiler can catch some but maybe you know better tool to handle this problem.
Thanks!
Yeah mostly that since we are streamlining composability we are replacing the
()(default arguments) with=(default attribute). In this way we can extend this capability out to custom tags you might author. Default attribute has some benefits in that it only accepts a single argument.So
<if(condition)>is now<if=condition>. How we handle backwards compatibility is still open but we wanted the preview to only contain future facing syntax to get a feeling for what the intended experience.As for the store, you could do it with just JavaScript to a point. The unit of change, the equivalent to React's
useStateor Vue'srefor Svelte'sletis Marko's<let>tag. So you could set and update that with JS from the outside but it wouldn't be granular. In the same way you need to update their core primitives you need to do so with Marko. So using the primitives in file makes it easier to make it more performant.It's a bit of a departure but we have primitives for Context API, etc for more advanced patterns, and more interestingly is tags let you colocate in the markup. Nest data exactly where you need to use it without additional imports etc. Not saying you would but when Marko 6 comes along you could make a whole app in a single template with no performance degradation. Components no longer are a limiting factor.
In some ways it's like the diagram when React Hooks came out that showed how we reduced the interweaving of logic compared to class Components. This takes it even further. Basically single cut and paste refactoring. Almost like dealing with plain HTML.
That being said it only raises the bar on tooling in templates. And on this we agree. Work in the last year from Vue and Svelte have given us a pretty clear trajectory in getting TypeScript, Prettier, and ESLint support. Things that these custom DSLs have always struggled a bit with. So this is definitely something being worked on. But as you can imagine with something so big coming around the corner it didn't make the most sense to develop that out with these changes coming down the pipeline.