I'm trying to use OrderedMap.merge to store application state using reflux (specifically reflux-immutable), but I noticed this does not translate Objects into OrderedMaps, but regular Maps, which do not guarantee order when iterated over. There are several parts of my application where I need order to be retained, so I was wondering if there was a way to accomplish this using OrderedMap.merge or something like merge. I came up with this, but it's super ugly and relies on ripping source code out of Immutable.js, which I'm not comfortable with.
Does anyone have any other ideas? Thanks in advance.
I decided to solve this problem a different way, namely by explicitly converting the objects I needed to be ordered maps prior to invoking OrderedMap.merge on the entire store's state. This works because the definition of merge essentially ignores objects that are already immutable, so there's no risk of duplicate work and merge's functionality is retained without having to do all the silly hacked together stuff I was doing.
Related
I've recently discovered the DOMStringList, which can be found in an IndexedDB's list of store names. It seems like a DOMStringList is just a simplified version of an array, which has only two methods item() and contains(). There is no useful methods like indexOf, filter, forEach that you'll find on an Array. Why use this kind of object? What are DOMStringList's advantages?
The existence of DOMStringList is a historical accident. Today, in modern APIs, the same use cases are met by using an Array instance.
It was introduced into web APIs because we needed something array/list-like, that cannot be modified. The "cannot be modified" part is important, because there's no good answer for what would happen to a modifiable array in scenarios like
db.objectStoreNames.push("foo");
db.objectStoreNames.push(notAString);
db.objectStoreNames.shift();
At the time the first API using DOMStringList was introduced, the people designing the API did not know how to make this work with Arrays. So, they designed DOMStringList. It was used for a couple of APIs, namely location.ancestorOrigins and db.objectStoreNames.
But then, the people designing such web APIs figured out how to introduce non-modifiable arrays. This actually took two separate tries:
Introducing the use of frozen Array instances, via the FrozenArray<> Web IDL type. See whatwg/webidl#52, and the linked bug there.
Introducing the use of proxies around Array instances, via the ObservableArray<> Web IDL type. See whatwg/webidl#840, and the linked bug there.
The difference between these two is that frozen Arrays cannot be modified, even by the browser; whereas proxies around Arrays can be modified by the browser. (Or even by the web developer, if the spec in question allows that.)
So, can we move everything using DOMStringList to use one of these modern solutions? No. Because there is code in the wild which depends on db.objectStoreNames.item() and db.objectStoreNames.contains() working, and that would break if we moved to actual Array instances, which don't have those methods.
So we might need a third Array wrapper type if we want to fully obliterate the legacy array-like classes from the web platform, and start using true Arrays. It would be a subclass of Array, with an extra method or two, and possibly a proxy wrapped around that. Nobody has yet made moves in that direction.
(Other legacy array-like classes, you say? Yes: in addition to DOMStringList, we have TouchList, AnimationNodeList, CSSRuleList, DOMRectList, FileList, ... see this list of classes on the web platform with an item() method, most (but not all) of which are of this sort.)
could someone please help me with all the possible options(or at least the most) on how to modify a store in Redux?
example: Object.assign(), (...spread operator) etc.
I need it to make my personal cheat sheet and maybe others could also find it here for inspiration, if it gets answered.
Thanks
There's pretty much two broad ways to do it. One you've already covered which is making a shallow copy of the old state and then changing values within the new object, and the second way is making a deep copy and changing values within the new object.
There are many different ways to go about doing each of these methods, like importing another library to give you a deepClone method or making your own.
The way you'd decide on which is better for your use case is to determine whether or not passing references between shallow copies will break your program or not.
I am using immutable.js in a redux application and I am wondering whether I should always use immutable.js datastructures where I would have used JSON object or array in a normal application.
Otherwise said, should the store of a redux application be a pure immutable.js datastructure or it's okay to mix with plain old javascript objects and arrays?
It's totally okay to use "old" javascript objects or array. If you use immutable.js everywhere, you will get more advantages than using "old" js objects. From their website, immutable.js is leading to much simpler application development, no defensive copying, and enabling advanced memoization and change detection techniques with simple logic.. It will enforce the use of functional programming patterns like pure function, which redux use a lot. You will avoid useless object mutation and related bugs. Your code will be more along the lines of the redux way of thinking. It might take more time to code with immutable.js, but your code will be better, faster and easier to update overall. Since you're using react. You won't get a lot of benefits using immutable.js inside a component because react has a great way to handle object change easily. I will suggest you to try to keep your redux store as pure immutable.js data structure as possible to avoid strange side effects and bugs. You will become used to it, but like I said before, it's totally fine to use non immutable-js data structure. Sometimes it will be easier not to use it. I will suggest you to try using it everywhere and you will be able to see by yourself if it's a waste of time or not.
After dabbling with javascript for a while, I became progressively convinced that OOP is not the right way to go, or at least, not extensively. Having two or three levels of inheritance is ok, but working full OOP like one would do in Java seems just not fitting.
The language supports compositing and delegation natively. I want to use just that. However, I am having trouble replicating certain benefits from OOP.
Namely:
How would I check if an object implements a certain behavior? I have thought of the following methods
Check if the object has a particular method. But this would mean standardizing method names and if the project is big, it can quickly become cumbersome, and lead to the java problem (object.hasMethod('emailRegexValidatorSimpleSuperLongNotConflictingMethodName')...It would just move the problem of OOP, not fix it. Furthermore, I could not find info on the performance of looking up if methods exist
Store each composited object in an array and check if the object contains the compositor. Something like: object.hasComposite(compositorClass)...But that's also not really elegant and is once again OOP, just not in the standard way.
Have each object have an "implements" array property, and leave the responsibility to the object to say if it implements a certain behavior, whether it is through composition or natively. Flexible and simple, but requires to remember a number of conventions. It is my preferred method until now, but I am still looking.
How would I initialize an object without repeating all the set-up for composited objects? For example, if I have an "textInput" class that uses a certain number of validators, which have to be initialized with variables, and a class "emailInput" which uses the exact same validators, it is cumbersome to repeat the code. And if the interface of the validators change, the code has to change in every class that uses them. How would I go about setting that easily? The API I am thinking of should be as simple as doing object.compositors('emailValidator','lengthValidator','...')
Is there any performance loss associated with having most of the functions that run in the app go through an apply()? Since I am going to be using delegation extensively, basic objects will most probably have almost no methods. All methods will be provided by the composited objects.
Any good resource? I have read countless posts about OOP vs delegation, and about the benefits of delegation, etc, but I can't find anything that would discuss "javascript delegation done right", in the scope of a large framework.
edit
Further explanations:
I don't have code yet, I have been working on a framework in pure OOP and I am getting stuck and in need of multiple inheritance. Thus, I decided to drop classes totally. So I am now merely at theoretical level and trying to make sense out of this.
"Compositing" might be the wrong word; I am referring to the composite pattern, very useful for tree-like structures. It's true that it is rare to have tree structures on the front end (well, save for the DOM of course), but I am developing for node.js
What I mean by "switching from OOP" is that I am going to part from defining classes, using the "new" operator, and so on; I intend to use anonymous objects and extend them with delegators. Example:
var a = {};
compositor.addDelegates(a,["validator", "accessManager", "databaseObject"]);
So a "class" would be a function with predefined delegators:
function getInputObject(type, validator){
var input = {};
compositor.addDelegates(input,[compositor,renderable("input"+type),"ajaxed"]);
if(validator){input.addDelegate(validator);}
return input;
}
Does that make sense?
1) How would I check if an object implements a certain behavior?
Most people don't bother with testing for method existance like this.
If you want to test for methods in order to branch and do different things if its found or not then you are probably doing something evil (this kind of instanceof is usually a code smell in OO code)
If you are just checking if an object implements an interface for error checking then it is not much better then not testing and letting an exception be thrown if the method is not found. I don't know anyone that routinely does this checking but I am sure someone out there is doing it...
2) How would I initialize an object without repeating all the set-up for composited objects?
If you wrap the inner object construction code in a function or class then I think you can avoid most of the repetition and coupling.
3) Is there any performance loss associated with having most of the functions that run in the app go through an apply()?
In my experience, I prefer to avoid dealing with this unless strictly necessary. this is fiddly, breaks inside callbacks (that I use extensively for iteration and async stuff) and it is very easy to forget to set it correctly. I try to use more traditional approaches to composition. For example:
Having each owned object be completely independent, without needing to look at its siblings or owner. This allows me to just call its methods directly and letting it be its own this.
Giving the owned objects a reference to their owner in the form of a property or as a parameter passed to their methods. This allows the composition units to access the owner without depending on having the this correctly set.
Using mixins, flattening the separate composition units in a single level. This has big name clash issues but allows everyone to see each other and share the same "this". Mixins also decouples the code from changes in the composition structure, since different composition divisions will still flatten to the same mixed object.
4) Any good resources?
I don't know, so tell me if you find one :)
All,
Further to my post here,
#Phrogz suggested we look into Kevin Lindsey's library for our needs of identifying the borders and applying restrictions. Has anyone got any experience of using this library?
THE PROBLEM:
In our web application we have an object made of SVG paths. We are trying to implement the functionality of drag and drop of other objects inside this object, with restrictions needing to be in place that the objects cannot be dropped outside the this SVG object.
Upon Phrogz recommendation, we looked into this but are struggling to make sense of how to pass the object. Do we pass the objects as path string or as SVG object.
ERROR:
At this moment, we are not getting any output, not even sure if its accepting the objects we pass through.
This is quite an open question and Im particularly keen on hearing from individuals who might know a thing or two about Kevin's library/ how it works/ functionality.
Cheers
I'm not sure how performant this will be for you. I wrote this library more as a proof-of-concept and to educate myself on intersections for higher order curves. That being said, I assume you are trying to instantiate instances of Path from the library? If so, have a look at loadShapes from the the following utility:
https://github.com/thelonious/js-intersections/blob/master/samples/IntersectionUtilities.js
That gets called on start when processing, say, this file:
https://github.com/thelonious/js-intersections/blob/master/samples/intersect_bezier3_rect.svg
Note that I'm tagging items to be process with a custom gui:edit attribute. That's neat and all, but I wrote this many many years ago (8+) and I'm sure the state of the art has better techniques, but I digress. The main thing is that you need to instantiate each shape type using the class for its node type. Each time you want to check for an intersection, you'll need to call Intersection.intersectShapes(node1, node2). That will return an object with a status attribute which will let you know if there was an intersection or note. I'm sure all of this can be improved. The code is up on github for those who wish to fork, fix, and improve :)
https://github.com/thelonious/js-intersections
https://github.com/thelonious/svg-2d
HTH,
Kevin