We Keep Coding

Is there any difference between class and staticClass in Vue.js?

Is there any difference between class and staticClass in Vue.js render functions? Using Template Compilation, I can see that it outputs different results depending on what is passed to HTML class attribute.
For example, when I pass a single string (for example 'foo') it outputs staticClass in data object:
<div class="foo"></div>
compiles to:
function anonymous() {
with(this){return _c('div',{staticClass:"foo"})}
}
but when I add a colon : (shortcut for v-bind) in front of class attribute it outputs class:
<div :class="'foo'"></div>
compiles to:
function anonymous() {
with(this){return _c('div',{class:'foo'})}
}
I am curious about the difference between class and staticClass, and which one should i use when writing own render functions.
I have googled a little, but have not found any clue.
Thanks in advance.

The key difference is that staticClass can only be a string. class supports all the other formats, such as arrays and objects.
The class attribute is special in many ways. For most attributes you can't specify both a bound and non-bound version on the same element. It also needs to be merged differently when combining the attributes from nested components. All of this merging happens here:
https://github.com/vuejs/vue/blob/531371b818b0e31a989a06df43789728f23dc4e8/src/platforms/web/util/class.js
When templates are compiled down to render functions they employ a number of undocumented features to take advantage of extra knowledge that comes from the template. This would be one such example, where it knows that an unbound class can only be a string so it tries to retain that knowledge by storing it separately as staticClass.
In theory there are a couple of advantages to that:
Manipulating the value doesn't need to worry about the array and object forms of class.
The staticClass can never change, so there's no need to check it when updating the DOM.
However, in practice that second optimisation isn't implemented (there's something that looks similar in the template compiler but it's not quite the same thing). Further, it's not entirely clear from looking at the code that there's much gained from a manipulation standpoint either. If anything it looks like it just makes things more complicated trying to maintain the two separate concepts right until the last possible moment. Perhaps the benchmarks suggest otherwise...
As for which one you should be using in your render functions, only class is documented so I'd stick with that:
https://v2.vuejs.org/v2/guide/render-function.html#The-Data-Object-In-Depth

Distinguishing between ImmutableJS and native JS data structures?

I'm writing a React component that I intend to make public, and I'd like to have it play nice either with JS arrays/objects, or immutable.js equivalents (Map/List).
What's the best way to identify an Immutable.js Map or List? I don't want to simply use Array.isArray, because I do want to enforce that it is either an Array or a List, for example.
I could just check for some of the Immutable.js properties, like _origin or __ownerID, but I don't want to depend on internal APIs that are subject to change in minor versions.

I would very much recommend the suggestions given by #robg and #joseph-the-dreamer. However, just for the sake of answering your exact need, for every Immutable.Type there is a Immutable.Type.isType() static function which you can use to determine if a given object is of that type.
E.g. Map docs -
var im = require("immutable");
if (im.Map.isMap(someObjectWhichMayBeMap)){
...
}

Laravel and variable naming conventions (snake case + camel case)

We are following the Laravel standard of naming model attributes as snake_case_variables. Although Laravel is just the API layer in our system that talks to a Javascript frontend and many other applications.
All the consumers of our API have a strong preference for camel cased variables (e.g. javascript / React).
We have found it difficult to change the core model attributes e.g. created_at, updated_at, confirmation_password, model relations etc into snake case.
we have toyed wth and implemented transform layers to change the "casing" coming in and going out, although this just add to maintenance and another thing for developers to remember...
How can we easily convert all model attributes, relations and general Laravel bindings into camel case?

I didn't recommend as it changes the core of the laravel and so its modifying vendor files and it won't be easy to update without loosing the changes, but I think the easiest way is to do this is to replace the vendor\laravel\framework\src\illuminate\Support\Str.php with a modified version. laravel performs all string modifications to studly, camel case, snake case etc from methods inside this file. go through the functions change the way the functions perform, but i don't think it will make sense as the method names wouldn't be matching to what they are performing.
Best but the hard way is to go into each files that is being using the methods in Str class and modifying acording to your needs, than it will make sense and yet a lot of work as you need to change the methods that are being used.
change the required values from these files.
see vendor\laravel\framework\src\Database\Eloquent\Model.php also you could see these values are set here for checking from models.
public static $manyMethods = ['belongsToMany', 'morphToMany', 'morphedByMany'];
const CREATED_AT = 'created_at';
const UPDATED_AT = 'updated_at';
see vendor\laravel\framework\src\Database\Schema\Blueprint.php also you could see these values are set here for checking from creating migrations and dropping migrations. for example the one that creates timestamps.
public function timestamps()
{
$this->timestamp('created_at')->nullable();
$this->timestamp('updated_at')->nullable();
}

You should definitely take a look at Mappable. We had the same problem, and this solved it. You can map snake_case to CamelCase names and even use them in QueryBuilder.

How to properly structure a KnockoutJS application

I am wondering how to structure a KnockoutJS application the right way.
The official documentation almost always uses just one single ViewModel!
After only a few implemented functions my code became very confusing and coming from an object-oriented background I am very allergic to architecture like that. So there must be a better solution.
Being not very experienced with JavaScript I was searching Stackoverflow and found those three options. So I tried the first two options and I am not happy with them:
Having multiple ViewModels like here.
I find it very difficult to decide what DOM-element gets what ViewModel. Also there were several functions called from outside the DOM-element. Maybe I used too little ViewModels with this kind of architecture but communicating between ViewModels seemed to be different and somehow shouldn't be necessary I hope. So how to do that properly?
Having sub views and utilizing the with binding (the second option from those three).
This was my preferred type of architecture because you can have document-wide bindings out of one view model but you can also structure your code into sub-chunks and bind them to wherever you want by using the with binding. This option though requires object literals instead of functions, which are inferior as described in this answer.
I haven't tried method three because it seems a little overkill and also uses object literals.
So is there a method to structure my code and also have full control without using object literals?
I hope this was not too confusing :-P

For any of the options that you mentioned, you do not need to use object literals. The samples just used them to simplify the code. You can choose to create the individual view models in any way that you see fit.
For example in #3, you can use a constructor function like: http://jsfiddle.net/rniemeyer/PctJz/149/. Of course, the actual data would get passed into the function rather than being static. Same with #2, you just would have it wrapped in the "View" object.

What is a javascript hash table implementation that avoids object namespace collisions?

First off: I'm using a rather obscure implementation of javascript embedded as a scripting engine for Adobe InDesign CS3. This implementation sometimes diverges from "standard" javascript, hence my problem.
I'm using John Resig's jsdiff library (source here) to compare selections of text between two documents. jsdiff uses vanilla objects as associative arrays to map a word from the text to another object. (See the "ns" and "os" variables in jsdiff.js, around line 129.)
My headaches start when the word "reflect" comes up in the text. "reflect" is a default, read-only property on all objects. When jsdiff tries to assign a value on the associative array to ns['reflect'], everything explodes.
My question: is there a way around this? Is there a way to do a hash table in javascript without using the obvious vanilla object?
Ground rules: switching scripting engines isn't an option. :)

You might be "asking the wrong question" (as Raymond Chen would say); rather than trying to avoid using the vanilla objects, try changing the way the associative array members are named.
The way I'd try to approach this: instead of there being an array member ns["reflect"], change the way that jsdiff builds the arrays so that the member is ns["_reflect"] or some other variation on that.

If the JS implementation you're using supports the hasOwnProperty method for objects, you can use it to test whether a property has explicitly been set for an object or the property is inherited from its prototype. Example:
if(object.hasOwnProperty('testProperty')){
// do something
}

Well given objects in javascript are just associative arrays, there really isn't another built in solution for a hash. You might be able to create your own psuedo hashtable by wrapping a class around some arrays although there will probably be a significant performance hit with the manual work involved.
Just a side note I haven't really used or looked at the jsdiff library so I can't offer any valid insight as per tips or tricks.