Popular posts

how would you design a two-way binding system

Why do you need this? Give me a real example and I will give you a code. Anyway if you need a general 2-way data binding only in sake of doing so it is in Vanilla JS already and is called a document.formName.elements.inputName.value

Isn't that just another framework?

No, BunnyJS is not a framework. You can think of it as just a set of components, helpers and polyfills united under same brand so you wouldn't need to search for another small thing yourself.

required writing extra helper code. That's all frameworks are

Can you tell me some of those helper functions in Angular or React?

Mev-Rael

Give me a real example and I will give you a code.

Let's consider what I presume is a familiar UI: the Gmail conversation selection checkboxes. Each conversation row has a checkbox next to it. At the top there is also a button/dropdown that sort of looks like a checkbox. Opening the dropdown reveals 6 options: All, None, Unread, Read, Unstarred, and Starred.

When one of the options is selected, all of the conversations in the list that correspond are also selected. For example, if the All option is clicked, then all of the conversations are also selected. When one of the checkboxes next to a conversation is clicked, the dropdown button must change accordingly. So for instance, if you previously clicked on All but then deselected a single conversation, the dropdown button would have to change to indicate that not all messages are selected anymore (Gmail indicates this with a square with a thick horizontal dash).

Now also consider that typing something into the search bar will repopulate the list of conversations shown but selections will remain intact. And the dropdown button will also change to reflect that in the new list not all messages are selected. And still more, typing something like "is:unread" should also change the selections accordingly

I will be thoroughly impressed if you can design this mechanism in vanilla JavaScript—which is obviously possible ipso facto it can be done with a framework— but also to do so in a manner

• That is repeatable — Because DRY and there are many other similar controls in Gmail. This isolated feature is not terribly difficult in vanilla JS but does not scale
• That is intelligible for others — No spaghetti code
• That does not introduce similiar code that a framework like Vue would use. Because then your claim that frameworks are unnecessary has been dismantled.

Kudos if you can also do so in a manner that is testable without the DOM.

Thank you, I will come back later this week with my thoughts.

Matt Strom :D lol

That does not introduce similiar code that a framework like Vue would use.

could you define this? ;D This is basically everything that could handle state and transfer it to a layout? or is it the way it's handled? :D to me due to a lack of precision (maybe on purpose) it's impossible.

Although in my head I have several solution prototypes. for example just creating own dom elements and collections using a classic event dispatch system for propagation.

you could create a tree structure that is component based where the html node is inside of the tress structure and hooked up.

you could try to use declarative model using selectors persist the state in the html.

the tricky part could be string parser. but than again .... a lib can already be just one reusable file Gg ..... it's a trick question to me ;D .... a nice one though.

@j Ha, I had thought about clarifying that, but it seemed like a difficult task. The distinction really hinges on when vanilla JavaScript or a library become a framework, at least to the degree that people here object to.

I'll take a crack at it. "Code similar to Vue or other frameworks" begins, I'd say, when you:

• Introduce some form of bindings, such as Angular's *ngFor or Vue's v:for.
• Introduce the notion of data contexts. So for example, a DOM element bound with an *ngFor binding is situated within a data context containing an array of items to repeat. Data contexts are hierarchical and share a similar shape to the DOM trees annotated with bindings
• Introduce automatic change detection. Some mechanism that can detect inconsistencies between the data model and the DOM and re-renders the component tree when a change is detected. React does this with the virtual DOM, AngularJS with the digest cycle, Angular 2+ with observables and Zones, and Vue with its reactivity system.
• Introduce a templating system that is capable of injecting values other than string literals (so this excludes native HTML templates).

How's that list sound?

Let's consider what I presume is a familiar UI: the Gmail conversation selection checkboxes

Assuming the elements are already on the DOM as:

#selectSome -- the select filled with options

#messageListBody -- the TBODY of a table where there is a TD in each TR that contains an INPUT of type CHECKBOX... since that IS tabular data a table would in fact be the CORRECT semantics!

... and let's for brevety sake assume those input are the first child element.

// we'll be walking DOM rows since tbody has no seperate rows collection :(
function walkChildren(parentNode, callback) {
    var e = parentNode.firstElementChild;
    while (e) {
        callback(e);
        e = e.nextElementSibling;
    }
}

function hookSelectToChecks(selectId, tbodyId, cellIndex, selectCallback) {
// cellIndex is which column (starting at 0) that contains the checkboxes

    var
        selectSome = document.getElementById(selectId),
        messageListBody = document.getElementById(tbodyId);

    selectSome.addEventListener('change', function(e) {
        selectCallback(
            selectSome.options[selectSome.selectedOption].value,
            messageListBody
        );
    }, false);

    walkChildren(messageListBody, function(tr) {
        tr.cells[cellIndex].firstElementChild.addEventListener(
            'change', function(e) {
                if (!e.currentTarget.selected) selectSome.selectedIndex = -1;
            }, false
        );
    });

}

// use 'new' so that locals are preserved for each call
new hookSelectToChecks(
    'selectSome', 'messageListBody', 0,
    function(selectValue, messageListBody) {
        switch (selectValue) {
            case 'all':
                walkChildren(messageListBody, function(tr) {
                    tr.cells[0].firstElementChild.selected = true;
                });
                break;
            // for fun, let's implement another
            case 'none':
                walkChildren(messageListBody, function(tr) {
                    tr.cells[0].firstElementChild.selected = false;
                });
                break;
            /*
                Implement all the rest of your unique conditions here. Note since
                we're iterating the full list of TR from messageListBody you can
                easily pull other data about the posts like read, unread, starred,
                and so forth from the cells off the DOM 
            */
        }
    }
);

Farking DONE. Hooks an existing markup so that you have the possibility of scripting off graceful degradation, leverages the markup and the DOM to do most of your heavy lifting as it SHOULD BE, walks the DOM instead of creating collections reducing the overhead... with a reusable function that gets passed a callback for the one part that needs to be customizable depending on data type.

Not even two minutes worth of coding... untested, may have typos, but this is simple stuff people! Hook the two parents, attach your listeners, walk the DOM. In Soviet Russia, the DOM walks you

Kudos if you can also do so in a manner that is testable without the DOM.

If you aren't working with the DOM what the blue blazes are you doing working with client-side JavaScript?!? What is this paranoid nonsense about bothering to leverage the actual form elements on the page to track what's going on -- that's part of what they're huffing there for PARTICULARLY for your scripting off graceful degradation. (where the select shouldn't even be in the markup and should be added to the script, but the checkboxes for mass actions should remain!)

I've seen a LOT of react/view fans say that, not to use the DOM to track what the user is doing with the DOM... where does this even come from?!? I think that might be a significant part of why I don't understand the react/vue mentality... which to be frank probably should have "more emphasis" on the mental.

Good scripting should be enhancing ALREADY WORKING MARKUP! and LEVERAGE the DOM to do most of the real work and actual data tracking client side! Is that the fundemental difference in attitude that separates the haters from the fanbois?

... because to be frank -- when am I ever anything else? -- all this talk about bindings and "data contexts" and all the rest of the academic double-talk REEKS of overthinking solutions to simple problems... and flipping the bird at the entire purpose of web technologies (in particular accessibility and scripting off graceful degradation) in the bloody process!