Deprecate <script> with export and <script template-helpers>
See original GitHub issueWe’ve decided to stop hijacking the script tag and use concise style tags that look like JS instead.
Deprecate <script>
with export
Old:
<script>
module.exports = {
handleClick() {
alert('hi!')
}
}
</script>
<button on-click('handleClick')>Click me!</button>
New:
class {
handleClick() {
alert('hi!')
}
}
<button on-click('handleClick')>Click me!</button>
Deprecate <script template-helpers>
Old:
<script template-helpers>
function sum(a, b) {
return a + b;
}
</script>
<div>The sum of 1 + 2 is ${sum(1, 2)}</div>
New:
static function sum(a, b) {
return a + b;
}
<div>The sum of 1 + 2 is ${sum(1, 2)}</div>
Moving to an external file
One concern you may have is that with the <script>
with export approach, the only change required to move a component to an external .js
file was copy and paste. Admittedly, it’s not quite that simple, but it’s still really easy.
This template:
import sum from './helpers/sum';
class {
handleClick(a, b) {
console.log(sum(a, b))
}
}
<button on-click('handleClick', 3, 4)>Click me!</button>
becomes these two files
component.js
import sum from './helpers/sum';
export default class {
handleClick(a, b) {
console.log(sum(a, b))
}
}
index.marko
<button on-click('handleClick', 3, 4)>Click me!</button>
So we copied over and had to add an export statement. Still pretty simple.
Issue Analytics
- State:
- Created 7 years ago
- Comments:42 (37 by maintainers)
Top Results From Across the Web
Add a way to write template code with a script tag inside the ...
Yes, I would make every .html file simply a module which exports all the templates defined there.
Read more >ES modules: deprecate export - javascript - Stack Overflow
The only solutions I came up with consist of using external libraries or wrapping the exported function in another deprecated function.
Read more >Chapter 4. Advanced topics Red Hat Enterprise Linux 9
Import the exported public key into an RPM database: ... Note that a package containing the scripts is installed between the %pre and...
Read more >SLES 15 SP3 | AutoYaST Guide - SUSE Documentation
AutoYaST is a system for unattended mass deployment of SUSE Linux Enterprise Server systems. It uses an AutoYaST profile that contains installation a…...
Read more >737044 - Deprecate importScripts for non-installed scripts
Pipe whether the script was installed to ResourceResponse. - In ServiceWorkerGlobalScope, if the script was not installed, print a deprecation warning.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yup, that’s what I am thinking and that is what we allow if you need to escape placeholders.
If you are good with it, then I propose we move forward with
$ <code_block>
and$${ <code_block> }
.If anyone has any last minute objections please let us know!
/cc @austinkelleher @philidem @mlrawlings @Hesulan @Eldar-X
@Hesulan What I meant is that the single line version, because we allow continuing, is also the multiline version. So If we wanted to have a different symbol (like
$$
) and didn’t want the single$
to allow multiline, it would take more work.Your logic is pretty much how I implemented it: https://github.com/marko-js/htmljs-parser/commit/21958233e1c4c442e8e338dc14c537b813ffab2a#diff-61eec70114a46820c77ce5879a128729R658
I’m going to close this as the work has been completed. Thank you everyone for your feedback and help in reaching this point!