Proposition for Basic Template View Support (Sort Of)

[Topher Fangio]

Hi all!

We've recently been discussing a variety of topics on IRC and I wanted to bring back up an idea for super-basic template support.

We've discussed how the existing SC.TemplateView is rather clunky and deprecated since it is no longer maintained. I've been trying to figure out a good way to support some basic template views without a lot of maintenance, change, or frustration; and after some research I've been doing, I wanted to shoot out a semi-formal proposition to get things started.

ECMAScript 6 is the latest JS language definition and is on track to be standardized in early-to-mid 2015. Many browsers are already beginning to support it, and there is a Traceur library which "transpiles" ES6 code to ES5 code so that it can run on older browsers.

One of my biggest gripes with custom SC views is that you have to do a bunch of ugly string concatenation and use of .fmt() to insert variables into strings. ES6 gives us a much nicer way of doing this with Template Strings.

Template Strings simply start and end with back ticks (`) and can have variables embedded through string interpolation. Here's a super-quick example:

    render: function(context) {

      var c = this.get('content'),

            styleClass = c.get('styleClass'),

            body = c.get('body'),

            html = `<div class='${styleClass}'>

                          ${body}

                        </div>`;

      context.push(html);

    }

As you can see, this code looks quite a bit cleaner than the normal render() code (at least that I produce) and being that this will be the standard soon, I feel like this would kill 80% of the frustration for a relatively small investment.

I believe the best way to support this would be with a plugin in the new build tools that passes everything off to Traceur as the last step, and I *think* that is all it that we'd need to do.

This would give us the added bonus of being able to try out some of the other ES6 features early if we wanted to.

I'd love to hear people's thoughts on this approach and if it would be a decent first-step.

Thanks!

--

Topher Fangio

Director of Software Development
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Maurits Lamers]

My first impression is that it would be an improvement for sure. It sounds pretty much like the Ruby technique to insert variable values in strings (#{varname})

I wonder however how we might be able to pull it of at all, as SproutCore itself very much still relies on ES3 arguments.callee.base.apply(), and I find it difficult to imagine to have part of the code require ES6/5 and other parts still running on ES3…

Thoughts?

Maurits

--
You received this message because you are subscribed to the Google Groups "SproutCore Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sproutcore-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Topher Fangio]

As far as I understand it, Traceur simply recognizes and compiles ES6 syntax into an ES5 equivalent syntax, so I don't think you actually have to change any of our existing code (although I must admit I am not positive).

The actually output strings in the .js file will look something like regular JS code. For example:

    var myString = `

    Hello ${name}!

    `;

will get translated into

    var myString = ("\nHello " + name + " !\n");

When I get the chance, I will try to run some more advanced SC code through Traceur to see if it even modifies it, but as far as I know it only recognizes/modifies ES6 syntax, so I think if we're not using the syntax, it will simply produce the exact same file (or perhaps a very slightly modified one).

You can play with a live demo at https://google.github.io/traceur-compiler/demo/repl.html which lets you play with the ES6 syntax and see what Traceur outputs.

--

Topher Fangio

Director of Software Development
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Nicolas BADIA]

I really like the idea ! Being able to use ES6 feature right now would be awesome, and I'm sure, it would make SC a bit more attractive.

About the implementation in the new BT, I think we should introduce a plugin system and include the traceur included as a plugin. 

With this plugin system, we could release the // @if (debug) @endif parseur as a plugin, which would make it more digest for the community to enhance it and add support for other keywords for example.

We could also move the css and js minifiers as plugin. This way, it would be easy to change the minifier if needed.

Moving some code as plugin would also make the BT core lighter and easier to maintain.

Thoughts ?

[Topher Fangio]

Hi Nicolas,

As far as I understand it, the new BT already revolve around a plugin architecture, so I think this fits right in. I'm not sure how the minification works, but I assume it is a plugin as well. Perhaps Maurits can provide a bit more insight :-)

--

Topher Fangio

Director of Software Development
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Maurits Lamers]

Topher, 

Nicolas knows the BT pretty well, as he already has been developing extra features. 

The BT do know have a plugin architecture, as it is an SC application. So, in that sense a plugin is essentially extending a specific type of object in which you want to have certain functionality.

cheers

M

[Topher Fangio]

Right, I'm in a bit of a spastic state today, so please forgive my incompetence :-)

Did you mean "The BT do now have" or "The BT do not have"?

--

Topher Fangio

Director of Software Development
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

[Maurits Lamers]

And perhaps something is autocorrecting or it is just me…  :)

the BT do NOT have a plugin architecture.

cheers

Maurits

[Nicolas Badia]

Hi Topher,

You will be happy to hear that traceur support just landed in the new BT.

Cheers,

---

Nicolas

[Topher Fangio]

Awesome!!! I'm sorry I haven't been around much recently; I'm actually in France at the moment working with a team here and I return to the states later tomorrow.

I'll definitely give this a try!

P.S. After dealing with Angular for the last 3 months, I REALLY miss the simplicity of SC :-(

--