We Keep Coding

Javascript sort function to place element in the middle of an array

Quite a few months ago, I tried to find a way to place an element in the middle of an array of 3 items using the javascript sort function. It looked like there was no clever way of achieving that result.
However, I recently found a working solution to this problem.
I then tried to generalize this solution to a bigger array of (5, 7, 9, ...) items. But, it seems to break when the size of the array exceeds 10 items.
Since I found the solution through trial and error rather than pure thinking, I hope someone is able to explain to me why everything seems to work fine until this seemingly arbitrary number.
Here is Codepen demo I created to illustrate the issue : https://codepen.io/TMLN/pen/PBoKgR?editors=0011
You can edit the line ReactDOM.render(<Example items={example1} />... and replace the prop example1 by example2, example3, ... You'll see that everything starts breaking from example5 but I really can't figure out why...
PS : this works on Chrome but for those using Edge, you might encounter a bug due to the way the browser handles the sort function.

Your sort callback function returns 0 when neither of the compared values is equal to the value to be moved. You probably intended to indicate with this zero that the relative position of a and b (the two compared values) should not change, but actually the zero means that the sort implementation should consider the two values equal, and so it is actually free to swap their positions. Only when the implementation is (what is called) stable can you be sure that the relative position of the two values will not change.
Others have found that in Chrome the sort function is not stable, which explains the erratic behaviour you notice. See this Q&A for the situation, with regard to a stable implementation, in different browsers.
To make it work on all JavaScript engines you should change your code, and return a non-zero value for all pairs you compare, based on the index they currently occupy.
Final note: using sort for this task is a bad choice: a good sorting algorithm has O(nlogn) time complexity, but if you need to find indexes of values inside the sort callback you actually add a factor n to that, making it O(n²logn). To get an element out of an array and injecting it elsewhere is an operation that can be done in O(n) time. You can use Array#splice (twice) to do just that.

Add entries to head of Map using immutablejs

I am working on react . using immutableJs for handling the states.
Suppose if i have Map type data. I want add the data to head.
If i use Map.set(key,value) it adds the value at tail.
For ex -
Immutable.Map({'testKey','testValue'}).set(message_id, anotherMap) // It adds the value at tail of the map.
I tried using concat https://facebook.github.io/immutable-js/docs/#/OrderedMap/concat like this -
MapIWantToAddAtHead.concat(olderMap)
but it doesn't seems to working.
I havent tried merge yet .
Is there any other way which i am missing to add entries at head.

Given you are using a Map, I take it that your use case involves keys and values. But for some reason not mentioned in your question above, you also want the new entries to come in the front. I am assuming you are doing this to be able to operate with them in LIFO fashion. And although mentioned fleetingly, you seem to be using OrderedMap which guarantees iteration order of FIFO.
If my assumptions are correct, you can simply invoke the reverse method on your OrderedMap to turn it into LIFO. This way you won't need to fiddle around with the insertion logic, and at the same time you will traverse the Map in the desired order.

Highcharts error when add and shift data to hidden series

So there seems to be an error when dynamically adding data to a hidden series in Highcharts.
Say I have two series on a chart that both update on the same interval of time. Say also that I'd like to ensure that neither of the two series have more than a certain number of points, therefore leading me to use the optional shift boolean during a series.addPoint() operation.
The problem I run into is that, if one of the series is toggled and made invisible for some time, when re-toggling that series, much of the data that should've been shifted is still present.
I've made an example fiddle of this (just toggle data1 in the chart legend for a few seconds and then re-toggle)
http://jsfiddle.net/mmuelle4/c00cLfs5/ (change funcToTest to see how various fixes don't quite give the "shift" look)
I'm using the latest version at the time of this post (Highcharts JS v4.0.4).
I think what I've uncovered is still an error that will need to be addressed by Highcharts, but I figured I'd ask the question - is there a better way to perform series length checking and data adding/shifting for multiple series than in the linked fiddle that would get around this issue? I can think of some clunky ones off the top of my head, but I thought I'd come to SO for some elegance :)
Link to bug on Github (for tracking): https://github.com/highslide-software/highcharts.com/issues/3420

You can workaround this issue by managing shift on your own. Simply store in some array all points and shift them there. Then call series.setData(array_of_points,redraw,animation) instead of series.addPoint(points,redraw,animation, shift).
In short:
when series is hidden use series.setData()
when series is visible use series.addPoint() with shift-param set to true|false

Is there a way to get around 'setData' on a highcharts area chart?

I have a working highcharts area chart, I initialize it with almost no data in its series, just 4 series with one point each. Then I call:
function(output){
var chart = $('#mychart').highcharts();
chart.series[0].setData(output[0]);
chart.series[1].setData(output[1]);
chart.series[2].setData(output[2]);
chart.series[3].setData(output[3]);
}
That works perfectly fine. Later on, the data gets changed and I call that very same function again, and it works, but the problem lies in the amount of time it takes.
I set up logging to log the amount of time that this single function took. The first time it runs it takes about 140ms, the following times when it updates, it takes an average of 2 seconds.
Why does it take so long? Is there a way to speed this up or get around it?

Sorry to post this question, but I will leave this answer here for anyone who encounters the same problem:
The problem was the data I was using. In the first iteration, I was using a simple array:
[123,912]
The rest of the time, I was using an array of objects:
[{y: 123},{y: 912}]
For some reason, that equates to having a different load speed. From now on, if a fast performance is required, it seems you have to do your part to help highcharts. I hope this helps somebody else who comes across this problem.

Method chaining- d3.js

It says method chaining in D3.js performs several actions in single line of code. But i am not sure how much it cares about performance while executing.
For example,
By method chaining ,we would like to put the code like below:
var data =[10,20,30,40]
wrap.selectAll("rect")
.data(data)
.enter()
.append("rect")
.attr("x",function(d, j) {return scale(j); })
.attr("y",function(d,i){ return (h-d)})
.attr("width",scale.rangeBand())
.attr("height",function(d,i){ return (d)})
.style("fill","red");
In the above code,it will generate 4 rectangles, then for each 4 rectangles we are setting the attribute "x","y","width","height".
No.of rectangles ---> 4 No.of attributes("x","y","width","height")
---> 4 No.of iteration for each attribute ---> 4 (sine 4 rectangles) No.of iteration for 4 attributes ---> 4*4=16 times
Is it really necessary of such number of iterations?Is it fast performance?
Normally we do like this,
wrap.forEach(function(d,i){
d.setAttribute("x", scale(i))
d.setAttribute("y",(h-d))
d.setAttribute("width",w)
d.setAttribute("height",h)
})
In the above method ,No.of iterations used --> 4
So whats the advantage of d3.js method chaining and selection.daa with the above mentioned conventional approach
Please clarify me??

I was thinking about this today.
I think there is a fundamental problem with chaining.
Namely, you cannot partition data into different shapes that easily. And, if you could, you can't assume similar attributes chained from different shapes. A square and a circle say, have different attributes to define their size and location.
But, assigned from this conflict, which is not resolved by symbols, there remains the question, which you have asked,
"Is it an efficient representation?"
It make the code look nice. But, in fact each one is a function call that can go down a deep stack for anything to happen. And, that's slow.
So, one begins to think of an alternative similar to your loop. Or, perhaps the attributes can be gathered and assigned in one last shot - almost a compilation.
Don't forget that JavaScript is interpreted.
It is easy to get deceived into thinking that JavaSript will provide the efficiency you are looking for in certain applications. Of course, a tired user clicking on this and that would not notice the difference. But, there is the animation and the interaction of working parts when changes cascade in some way. Certain applications really need the efficiency.
Even the forEach that you are using can be suspect. I was working with a younger programmer last year, using D3. And, there was some part of one of our displays that ran woefully slowly. (A tired used would have certainly been awoken into a tizzy.) We took it out of the forEach and ran it in a regular "for" loop construct. Then, the same code ran with incredible speed. So, there are parts of JavaScript that are not as ready for prime time as you might think.
It is probably better to use many of the new constructs that are making their way into the language for many parts of an application. But, when it counts, you might wait for some update and use more optimized parts of the language.
I am fairly sure that d3 is not optimal in setting attributes. And, now I am trying to think of some better representation than chaining.

Remember the act of iterating itself is negligible. If the cost of setting an attribute was 1 you are comparing 16 * 1 with 4 * 4. Therefore it's not really a big problem. The chaining is a matter of concision.
Using Big O notation to analyse the algorithms, both are O(n).