BoundComponent Template Strings

The BoundComponent class includes functionality for inserting variables into strings that are displayed. Typically this is done with some variation of handlebars.js, something like <p>Hello {{planet}}</p>, or if you're using HTML5 template strings (which are misnamed because they don't work as templates), <p>Hello ${planet}</p>. Ichigo takes a different approach. Ichigo's templating language is more integrated with HTML, because Ichigo is a framework for producing web content. Content to be replaced by a bound string must be stored in an "i-v" HTML element containing a variable or parameterless function, as in the following example:
<p>Hello <i-v>planet</i-v></p>

At this point you might be wondering why Ichigo uses something odd when all the other web frameworks use some variation of handlebars templating. Is it just to be different? Well, no, it's to make the framework programmer's life easier. If at this point you're thinking, "Oh, what a lazy bastard," you can FUCK RIGHT OFF! Ok, that's a little confrontational, sorry, but I'm not going to write sloppy code just because everyone else does. TBH I did actually write it a few years ago. It had a lot of regular expressions. Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. Then I realized that I'm not building strings but browser content, and browsers already have a way to isolate elements, fill content, and escape tags. It's called the document object model and it's been around for how many years -- really I'm asking, how many years, I'm having a hard time finding the starting point ... seems to be 1997 ...

Anyway, that went way off into tangent-land, but the point is that values to be replaced are just HTML elements like spans. This implementation allows the framework code to fill them using standard HTML5 methods that exist in every modern browser, a fact which allows the framework programmer to sleep at night without feeling like he hacked some shit up. As sleep is critical for human health, this makes life easier.

Hello planet. I come here from ..

This is a list of neighboring planets who have asked me to mention them to any intelligent beings I met on my way to .:
    advertising

A text item to be replaced with bound text should be inserted as an <i-v> tag, where the content is a property of the object bound to the component, as in the following example: <div id="test">My name is <i-v>name</i-v></div> bound with new BoundComponent({ name: 'Sam' }, { selector: '#test' }).

The innerHTML of the i-v element is the property name, found on the component view model, to use for the new content of the element. It can also be a method of the view model; if used, the method is called with no arguments ( for now). It can also be the view model itself -- to do this, set the innerHTML to a period by itself (<i-v>.</i-v>) -- this can make sense if the view model is a simple object such as a string and makes no sense if you display [object Object].

By default the replaced content is HTML escaped. If you want it to be raw text, allowing HTML tags to appear in the output, add a noescape attribute, as in <i-v noescape>.

By default, all i-v elements are bound to a component and replaced. If you want to include a tag inside multiple nested components, and only want to associate the element with one of them, add the id of the component after a pound sign, as in <i-v #inner_component>, or use the "component" or "data-component" properties ( <i-v component="inner_component">). This check is case-insensitive.

One of the optional, rarely used, but occasionally useful possibilities is to use a different component on the page as the data source. This can save you some custom coding. The :source attribute tells Ichigo to look for the component on the page (it has to show up in document.getElementById()) having that id and use that as the source. View model references come from that component, as do "this." (references to the component).

Consider the following two examples:
<subject-line id="subject"><i-v #subject>.</i-v> <from-line id="from"><i-v #from>.</i-v></from-line></subject-line>
<subject-line id="subject"><i-v #subject>.</i-v> <from-line id="from"><i-v #subject :source="from">.</i-v></from-line></subject-line>

These two examples would show the same data, but they are not the same. In the first example, the from line can update when the from line is changed and the subject line can update when the subject line changes, each with their relevant values. In the second example, the subject line still comes from the subject component and the from line still comes from the from component, but both tags are bound to the #subject component ... only a change in the subject line will change them.

Changing the source allows you to pull data from components found in a completely different part of the page. Of course you could already do that by using a method as your source, but this saves you some coding.

When a component is initially rendered, i-v elements are replaced with their expected values. When the component is re-rendered (because it observing object changes, for examples), i-v elements are re-populated. i-v elements are regular HTML elements, so they can take styles, CSS classes, etc. Unless you choose to destroy them (by, for example, setting innerHTML of a parent), these i-v elements stay where you left them, so they can be safely referenced in code.

Link to the demo script