getify / grips Goto Github PK

grunt task needed.

I was pinged on twitter about this, opening a ticket since talking on twitter is hard to do.

What is used depends on if there are dependencies for the file. If not, and if you are building up an "exports" object to use say in node, you can just do something like this at the bottom of the file:

var exports = {};

//build up the library

if (typeof define === 'function' && define.amd) {
    define(exports);
}

If you want to return a function as the module definition, then I do:

function grips () {};

//build up the library

if (typeof define === 'function' && define.amd) {
    define(function () {
        return grips;
    });
}

If there are dependencies for the in-browser case, then something like this may be more appropriate:
https://github.com/umdjs/umd/blob/master/amdWebGlobal.js

which does a browser global, or if AMD is available, does AMD.

If I got the use case wrong though, feel free to clue me in. If you will be doing a build that mandates AMD is in play, then for the above samples you could remove the if() test.

The utility would output JSON with keys representing each variable referenced in the .gcss file.

If you call render() without specifying either a $ (data context) or $$ (local variable context) param, those both need to default to empty objects. Sometimes you want to render a partial and it needs no data, or the data is entirely conditional/optional.

finally get this packaged and released. duh.

just like the title says.

{$# foo = "foo"}{$} works, but {$# foo = "foo" | bar = "bar" }{$} will trigger an error TokenizerError: Unexpected token; |;

Whenever selectors are processed by the codegen, and they are base64 encoded for the grips partial id's, these selectors need to be normalized. Whenever render(..) is called with a selector, that selector should be normalized, so it can match when base64 encoded the proper grips partial.

Examples of necessary normalizations:

foo     bar

-> foo bar

foo     >       bar

-> foo > bar

foo    /* something */    bar

-> foo bar

Which wouldn't be such a bad thing if I wasn't also looking for deferred to work (which I am going after next)...

I would have expected:

        publicAPI.fulfill = function(val) {
    fulfill.call(publicAPI,val);
        };

To do the trick, however, the internal queue is always at 1 in this example:

var p = Handlebar.Promise();
p
.then(function(P) {
this.fulfill('foo'); //took me a second to realize this is the API and P is generally an object just for holding the value...
})
.then(function(P) {
console.log(P.value);
})

Unsure what I am missing, as the internal fulfill function is in use and working... just can't figure out how to expose it properly.

Minor general optimization (but will happen a lot with grips-css):

m = m ? m : 5

can be optimized to:

m = m || 5

For instance, if I do:

<ul>
{$* data.pages | caption=item.value.name?'<span class="caption">'+item.value.name+'</span>':'' $}
    <li>{$= data.caption $}</li>
{$}
</ul>

The output is:

<ul>
<li><span class="_.caption">foo</span></li>
</ul>

The extra _. is rather odd.

This should work:

{$let a = 2 | b = 3 } .. {$}

But it throws an error about | being an unexpected token. Boo.

Not exactly what you're thinking, probably. Adding sourcemap support means that grips.render(..) would be able to accept a sourcemap to map the line/column values reported in any errors back to an original file.

What kind of original file if not the grips template itself? Good question.

grips-css is going to produce standard grips template files from gcss (grips-css) style files. So it'd be very nice if grips.render(..) could map any errors back to the original gcss file instead of the generated grips template file.

Forseeing possible other applications, where tools could auto-produce grips templates from other files, like source HTML files, other templates (aka, template conversion, etc), and the like.

It's a separate but related task to have grips compile (and of course, grips-css compile) produce sourcemaps.

And it seems that Handlebar.DataClient just doesn't exist, and I cannot find it in the source either.... ? Perhaps the example needs updating? Or is this just a placeholder that I don't understand?

In the local-loader JS file, require("FS") is being used, I think that is a bit of LABjs that slipped in there? or something is missing?

And finally JSON.minify is undefined as well.

Any help/pointers/updates would be very grateful.

Consider:

#box1 {
   color: red;
   font-weight: bold;
}

#box1, #box2 {
   color: green;
}

#box1 {
   background-color: blue;
   font-weight: normal;
}

Currently, the first #box1 ruleset would be "lost" (that is, not template renderable) because grips treats the selector as the template ID, and duplicate template IDs overwrite previous ones.

One solution would be to numerically index them to keep them separate and separately renderable. But that sucks, because then you have to know that and keep track of their order in your grips-css sheet, etc. Ugh.

The most workable solution is probably to handle this "lost" rule by dropping it verbatim (not as its own partial) into the #all template partial in the correct location. So, that might end up looking like this compilation:

{$: "#I2JveDEsICNib3gy" }#box1, #box2 {{$= @"#I2JveDEsICNib3gy_" $}}{$}
{$: "#I2JveDEsICNib3gy_" }
   color: green;
{$}


{$: "#I2JveDE=" }#box1 {{$= @"#I2JveDE=_" $}}{$}
{$: "#I2JveDE=_" }
   background-color: blue;
   font-weight: normal;
{$}


{$: "#all" }
#box1 {
   color: red;
   font-weight: bold;
}

{$= @"#I2JveDEsICNib3gy" $}

{$= @"#I2JveDE=" $}
{$}

This way, we preserve the "lost" rules without needing them to be individually renderable (you would have to re-render the whole stylesheet to re-render that "lost" part).

Note: This means any of the templating dynamics (like variables, embeds, nesting) of that "lost" ruleset also need to be merged into #all, so that they occur when the whole stylesheet file is rendered.