[joshstrange]

I use something a little similar where I work. No one would be on board with something like React but I've documented a way to write our code that does something similar to this post. We use js "classes" (Both Function.prototype and now js classes with babel) and lo-dash templates to make it a little nicer.

Example:

    function MyComponent(element) {
        var instance = this;
        instance.element = element;
        instance.history = [];
        instance.state = { myKey: 'someData' };
        instance.template = _.template($('my-template').html());
        instance.setupHandlers();
    } 

    MyComponent.prototype.render = function() {
        var instance = this;
        instance.element.html(instance.template(instance.state));
        instance.history.push(deepcopy(instance.state));
    }

    MyComponent.prototype.undo = function() {
        var instance = this;
        instance.state = instance.history.pop();
        instance.render();
    }

    MyComponent.prototype.setupHandlers = function() {
        instance.element.on('change', '.my-input', function(e) {
            instance.state.myInput = $(this).val();
            instance.render();
        });
    }

    

This is of course a very simplified version but it should give you an idea of what I'm talking about.

[mrspeaker]

I like how you redundantly alias `this` to `instance` except in the only method that needs it ;)

[joshstrange]

Haha yeah that was stupid. With the fat arrow "=>" I'm hoping to be able to get rid of it in most instances. I know I could mix this/instance but I'd rather use "instance" everywhere for consistency even if "this" works. I'd love to hear other's thoughts on the matter!

[aikah]

You're example is the perfect example of what not to do and why React, Angular and such exist: STATES. You want your view to be data driven.It means that your component should be STATELESS.

There are other issues such as event delegation,cleaning up event listeners,... that will make your solution hard to scale past simple widgets.And before you know it,you'll be writing your own complicated framework that does less than Angular or React.

[joshstrange]

> that will make your solution hard to scale past simple widgets.

I am fully aware of this issue, again, this is a stop-gap between the jQuery mess we had and proper framework. This is not being used to run the whole front-end, it's only being used for components that are loaded on a page. And in fact the one page that we have that does a full re-draw on every change is actually extremely fast, you don't even notice it. Again, this is not to say it's the end goal, just a step on the staircase to a JS framework. Just getting away from building a component in PHP then modifying it in JS has been a huge win. My rule of thumb is logic should only be implemented in 1 language and so if you need to update/modify anything on the client side (which we almost always need to do, this is a Web App and not a website with some JS sprinkled in, even if that's how it started) you need to do it all in JS or else you get into a case all too easily where you edit the JS or PHP and not the other. Not to mention that if we wanted in the future we can alway render the first load on the server (using JS) and then subsequent renders could happen on the client with the same code.

[skybrian]

A web app always has a state machine somewhere, even in functional languages. The question is whether the app's state is internal (mutable state) or external (write a state transition function and let the environment pass the state back to you on the next iteration).

I think the jury is still out on whether storing all application state in a single state object (as in Elm) scales well beyond toy examples. All the state is exposed which doesn't seem so good from a data-hiding point of view.

[baddox]

> I think the jury is still out on whether storing all application state in a single state object (as in Elm) scales well beyond toy examples.

I'm not familiar with Elm, but what do you mean by this? Even if all the application state isn't literally in a JS object like {users: [...], messages: [...], ...}, it's going to be in multiple variables like UserStore and MessageStore. There's really not a big difference other than the syntax of accessing them. But perhaps you're hinting at a drastically different approach to application state.

[skybrian]

Elm [1] is not JavaScript. It's a pure functional language that compiles to JavaScript. There are no mutable variables in Elm as you'd normally think of them, but there are streams (called signals) and state machines.

The issue is that you can't really write UI components as you'd normally think of them; everything needs to be divided up into a separate models and view functions. The state of every single widget in the page (recursively) needs to be represented somewhere in the application model.

[1] http://elm-lang.org/

[donw]

It seems to work reasonably well for the two non-toy apps I've worked on that use a single state object. There are two key rules required to make this work, however:

1. For each domain, state can be modified in one place (in React, a store).

2. For each domain, state can be read in once place (a Presenter).

This preserves data-hiding for the most part, and keeps you from having to play hunt-the-wumpus when you need to change the data structure.

[i_s]

Om also stores all app state in a single object, but lets you give components a window into that state ('cursors') in order to maintain modularity. If there turns out to be a problem with this general approach, it won't be a data-hiding one.

[mambodog]

It's sad that your colleagues' lack of open-mindedness about adopting a framework is forcing you to create a less-well-specified, less-documented, implicit framework.

[cozuya]

I think its more surprising that his/her collegues are down with ES6 through babel but are yet scared of something like React..

[joshstrange]

We are using babel because I already got gulp into our code base and so adding babel was pretty easy to get in (also the benefits were easy to explain). While I could slide react/angular in our bower config easily I would need to document how to transition from what we have to the new JS framework. More than anything I worry about moving too fast. Getting switched from jQuery mish-mash of code (global functions and variables everywhere and everything in a doc-ready) to what I have above was a big hurdle that we still aren't over. I'm trying to ease everyone in without leaving anyone behind. I know what we are doing isn't the best approach but it's better than what we had before and will be many times easier to move to a JS framework.

[joshstrange]

As I said in the reply to the child comment it's more of a "we can't move that quick without people falling off". I'd love to adopt a JS MVC or even just something like React but it would be too much of a change. I'm trying to ease everyone in with a combination of ideas that I've pulled from various frameworks. I don't for a minute think what we are doing is the most efficient (redrawing the entire view for every little change? Terrible) or even best practice but we have to start somewhere and trust me, anything is better than what was there before. I'd love to hear ideas on a better way to accomplish this and ease the transition.