My favorites | Sign in
Project Home Issues
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 2203: removeEventSource not working with array
6 people starred this issue and may be notified of changes. Back to list
Status:  Released
Owner:  ----
Closed:  Aug 2014


Sign in to add a comment
 
Reported by bhol...@snapappointments.com, Jul 11, 2014
Since the update to 2.0+ removeEventSource no longer works properly. Please see this example for a simple demo:

http://jsfiddle.net/Wu9FP/1/

We pull in an array of all events across all calendars from a single JSON source for efficiency. We then loop through each calendar to add the events. addEventSource still works as it always has; removeEventSource does not remove the source from the calendar.

We have a list of calendars that can be selected an deselected so, as a temporary workaround for a deselected calendar, we are forced to use "removeAll" to remove all event sources and then we have to process all other calendars again to add them back to the calendar.

I realize we could pass IDs/etc or even use classes to hide the events via CSS but we would prefer to just use the "removeEventSource" fullcalendar function as we always have.
Jul 12, 2014
#1 bhol...@snapappointments.com
I believe the issue is located within the buildEventSource function which is called within addEventSource in 2.0+. The modifications made to the object here are not reversed when "removeEventSource" searches for a match.

Here are the relevant snippets from 2.0.2 buildEventSource:

-----1492:1495-----
function buildEventSource(sourceInput) { // will return undefined if invalid source
   var normalizers = fc.sourceNormalizers;
   var source;
   var i;
-----fullcalendar.js--2.0.2-----

-----1503:1526-----
else if (typeof sourceInput === 'object') {
   source = $.extend({}, sourceInput); // shallow copy

   if (typeof source.className === 'string') {
      // TODO: repeat code, same code for event classNames
      source.className = source.className.split(/\s+/);
   }
}

if (source) {

   // for array sources, we convert to standard Event Objects up front
   if ($.isArray(source.events)) {
      source.events = $.map(source.events, function(eventInput) {
         return buildEvent(eventInput, source);
      });
   }

   for (i=0; i<normalizers.length; i++) {
      normalizers[i].call(t, source);
   }

   return source;
}
-----fullcalendar.js--2.0.2-----

1.6.4 uses the "_addEventSource" function instead, which is as follows:

-----1088:1100-----
function _addEventSource(source) {
   if ($.isFunction(source) || $.isArray(source)) {
      source = { events: source };
   }
   else if (typeof source == 'string') {
      source = { url: source };
   }
   if (typeof source == 'object') {
      normalizeSource(source);
      sources.push(source);
      return source;
   }
}
-----fullcalendar.js--1.6.4-----

Obviously reverting the addEventSource functions is not the ideal solution; the removeEventSource function simply needs to be modified to handle this change. Hopefully a project team member can respond with a patch/workaround and resolve this bug for 2.0.3. While we have a strict policy restricting any modification to 3rd party contributions, we will likely have to make an exception for now.

Appreciate all of the hard work.
Jul 12, 2014
#2 bhol...@snapappointments.com
JS is not my forte, but obviously this is a somewhat major bug for anybody using an array for their source. It's likely it won't be addressed for some time so I have solved the issue, albeit not in the most efficient manner, by making the following modifications:

function removeEventSource(sourceInput) {
   var source = buildEventSource(sourceInput);
   sources = $.grep(sources, function(src) {
      return !isSourcesEqual(src, source);
   });
   // remove all client events from that source
   cache = $.grep(cache, function(e) {
      return !isSourcesEqual(e.source, source);
   });
   reportEvents(cache);
}

function isSourcesEqual(source1, source2) {
   return source1 && source2 && getSourcePrimitive(source1.events) == getSourcePrimitive(source2.events);	
}

function getSourcePrimitive(source) {
   for (var key in source) {
      return ((typeof source == 'object') ? (source[key].id || source[key].url) : '') || source;
   }
}

As outlined in my above comments, the issue is that when a source is added via array, it is converted to an object. When the same array is entered in the "removeEventSource" function, it is not converted to an object and returns undefined during the comparison. This fix simply passes the array through the "buildEventSource" function in "removeEventSource"

The specific way my data is formatted (and yours may be the same way) required the modifications I have made in the "isSourcesEqual" and "getSourcePrimitive" functions. Essentially, these functions were not handling multiple-event objects properly.

So these modifications solved the issue for me... but mileage may vary. That being said, there is surely a better way to resolve this issue and hopefully it is addressed soon. It's always frustrating when new versions break functions that worked fine in previous versions.

Jul 14, 2014
Project Member #3 adamrs...@gmail.com
(No comment was entered for this change.)
Status: Reproducing
Labels: Type-Bug
Jul 14, 2014
Project Member #4 adamrs...@gmail.com
i see your jsfiddle uses v2.0.0.

v2.0.2 has a bunch of bugs fixed related to event sources:
https://github.com/arshaw/fullcalendar/releases/tag/v2.0.2

please trying using the latest version and then report back if your problems went away. thanks a lot
Jul 23, 2014
#5 bhol...@snapappointments.com
Sorry about that - I simply used the JSFiddle linked to on the "bug reporting" instructions - I am using 2.0.2 in my project with the same result and have updated the JSFiddle to 2.0.2:

http://jsfiddle.net/Wu9FP/4/

As I mentioned, I do have a workaround in place that solves the issue for my specific situation but it isn't a universal fix (nor is it very efficient). As I am using nodejs to monitor the calendar cache and automatically push the arrays to the calendar page on changes, our installation is quite complex and it always makes everybody nervous when we have to use open source projects that require modification. 

Basically, the issue is that arrays are being converted to standard event objects when they are added but when you attempt to remove the array source, as the conversion is not taking place, there is a mismatch.

Just to let you know, I have found the same issue being inquired about in a few other places by various people (including Stack Overflow) without any responses. I would offer to help but was hoping an official release would resolve this issue in a timely manner.

Appreciate all of your hard work! We have things working quite well despite this minor workaround.
Jul 24, 2014
#6 bhol...@snapappointments.com
If you were curious... this bug still remains in v2.1.0-beta1 (the applicable code remains unchanged - array sources are converted to event objects... when you attempt to remove the same array source no match is found as it is comparing an array to an object).
Jul 25, 2014
#7 bhol...@snapappointments.com
Unsure why this has not been accepted yet (cut and dry issue that is extremely simple to reproduce using the JSFiddle link provided) but with all of the updates that have been rolling out it's getting pretty repetitive having to hack things up every time and loading my custom copy instead of just using the CDN. Please add "skeleton" label as the exact same issue remains as of v2.1.0-beta1 (the applicable code resulting in this bug has remained 100% identical since 2.0.0).
Jul 28, 2014
Project Member #8 adamrs...@gmail.com
Thanks for the report and sorry for your troubles. I can confirm this is still a problem in 2.0.* and "skeleton".

The code you show in the fiddle would have *never* worked actually. You need to pass in the original array that was used in the addEventSource and call and pass that to removeEventSource. The removal relies on comparing the array references (comparing all items would be extremely expensive).

However, since 2.0.1, that wont even work. Because of this code (which was done to fix another important issue):
https://github.com/arshaw/fullcalendar/blob/v2.0.2/src/EventManager.js#L262-L267

This is a legitimate bug and I plan on fixing it for the next version. If 2.1 starts taking way to long I may have to release a minor version update.
Status: Accepted
Jul 28, 2014
#9 bhol...@snapappointments.com
Absolutely no need to apologize - as a developer myself, I understand that continued progress can create new issues and it's an extremely complicated process (especially with a project such as this where it has to fit into so many different environments and uses). You have stood by and maintained this excellent project for years and I am extremely impressed by your dedication here. 

Yes - expensive indeed; apologize for the flawed JSFiddle (which likely just complicated things further). My concern was that with all of the rapid progress you guys are making, this issue would continue to be overlooked due to using a dated version of fullcal on the JSFiddle. 

Appreciate your acceptance of the bug - just glad to see it's in the queue at least. Thanks again for all of your effort - we will certainly be donating to your project.
Aug 6, 2014
#10 julien.o...@nexonia.com
+1 

Hi everyone !
I got the exact same problem and I fixed it with the suggested workaround ! Thanks for that one ;-) !

However, I still have an issue with the following behavior :
Here is a JSFiddle to point out the problems I meet :
http://jsfiddle.net/juorain/w4uky1z1/1/

Scenario :
- click add event source : will add the source with one event to the calendar
- click add event to source : will add one event to the list
- click refetch : will do nothing. However, we are waiting for the calendar to print out the second event
- click once again to add event source : will show 2 events corresponding to the first one, and a other one for the last one added on the source.

Is it linked to the issue introduced in this ticket or need I to create an other one ?
Any idea on that point ?

Thanks in advance !
And congrats for this amazing project !!

Julien
Aug 19, 2014
#11 m...@human.x.ai
wow nice, can confirm the fix is simple and works for removing event sources with an array of events
Aug 19, 2014
#12 m...@human.x.ai
ah I sort of take it back... the fix only works for the fullcalendar version where the argument is "sourceInput" .. but now I can't find which version that was. I've tried adding it to various other versions (2.0.2, 2.0.3, 2.1 beta-1,2.1 beta-2) and none of them have the argument as "sourceInput" but also the fix also doesn't seem to do anything.
Aug 20, 2014
#13 bhol...@snapappointments.com
"sourceInput" is simply the variable name assigned to the source as it is being passed to the function - the variable name itself is not significant as long as you are referencing the correct variable within the function.

I have not checked the code for 2.0.3 or 2.1 beta-2 or beta-3 but I know that this issue exists in 2.0.0, 2.0.1, 2.0.2, and 2.1 beta-1 and can be handled using this "fix" - since a fix still has not been implemented, I'm assuming it still exists. Without a workaround here you essentially cannot use array sources in a production environment.

Again, this is not the perfect solution - it's simply a workaround for those that rely on array sources (especially in our case where we pull in multiple sources via a single URL to reduce http requests). As you can see in the JSFiddle, even extremely basic array sources cannot be removed as no match is found.  

I have other issues to report but honestly don't want to distract from getting this resolved as it is priority #1 for us and the only thing keeping us from putting 2.0.x into production - it should be a very simple fix and it would save me from having to update this bit of code every single time a new version is released. Until this is addressed, I'm done even testing the new versions.
Aug 21, 2014
#14 gdlinden...@gmail.com
Hi guys,

I was using 2.0.3, and tried the fix and now my events wont show, also I tried with the latest beta3 (it seems that the bug is still there), and I couldn't make it work either. Any suggestions?

Thanks.
Aug 21, 2014
#15 murrayc...@gmail.com
It's possible the "fix" isn't working in the latest versions. OP admitted it wasn't a 1-size-fits-all fix and it's definitely quick and dirty. Hopefully he has a better fix now that it's been 1 1/2 months as it doesn't seem like a very complex issue. I think the main problem is that the developer just doesn't understand the issue. This functionality was there before 2.0 but was broken in 2.0 because they are only converting arrays to objects when adding but not when removing. Not everybody adds events in this manner so a lot of people just don't notice the problem. It's a major issue and we're just sticking with the old 1.x until there is an official fix. I'm surprised it's taken 1 1/2 months for something that should be less than 10 lines of code but I don't know for sure what all is linked up so I don't want to mess with it. It's unfortunate because other than this everything else seems like it's been improved but this is a deal breaker and means we'll be stuck on 1.x for a while. Maybe they will add some of these fixes to 1.x if they aren't interested in fixing this issue on the newer versions. The way our calendars are served we don't have the option of switching the way we use fullcalendar.

Summary: If the developer isn't going to fix this can the OP at least let us know what their latest workaround is? A ton of less important issues that were added much later have already been addressed but this one continues to be overlooked. I'm willing to try implementing a fix if it's a bit refined. 
Aug 21, 2014
#16 gdlinden...@gmail.com
I think the DEV has clearly stated that he'll fix it, we, of course, don't know when, but for an open source project, I'm not complaining. It isn't like we've payed for it's commercial support or something.
I was using 1.x also, and I've upgraded to 2.x and had this bug, so I say +1 on the request for the OP, if he can publish how to make the fix work.
I'll be switching to 1.X if I can't make it work, but it was a lot of hard work switching to 2.X to now switch back :(
Aug 21, 2014
#17 bhol...@snapappointments.com
I will test the latest beta today and put together a better fix. As major as this issue is, the fix should be pretty simple. We decided to just stick with 1.6.4 for now as it's a bit concerning this functionality has now been broken for nearly 3 months (I'm starting to think the dev has decided not to address it as he doesn't understand our use case). 

As mentioned, when you add an array source it is converted to an object. When you go to remove that array source, the conversion to an object does not take place so it's trying to match an array to an object... not finding the match... and removing nothing. Obviously there is no need to ever compare a raw array since it's impossible to add a raw array without converting. The bottom line is that most people are not adding sources this way... so most people don't understand why this is a problem. 

It worked fine in 1.6.4 because the array was never converted to an object. Perhaps I will create a branch specifically for arrays if support for native arrays is going to be dropped. If the dev hasn't commented by the end of the month I'll fork the code and post the link here. There are at least 4 issues on Stack Overflow regarding this issue as well... almost all of them with no response. If support for this functionality is going to be dropped we just need to know... but it's just frustrating seeing 5 new versions released since I posted this issue, getting excited every time, and quickly realizing none of them address the issue. Not implementing new features is one thing but it sucks when new versions break existing functionality. A ton of improvements have happened here but I'm still stuck using a version that was released a full year ago because it's the last version that worked for us.
Aug 21, 2014
#18 bhol...@snapappointments.com
Just an update on my previous workaround: nothing has changed in 2.1.0-beta3 regarding this issue and the same "fix" still works. I will dig into it deeper this evening and try to put together a more permanent (and less "expensive") solution.

---removeEventSource function---
- Line 1559: function removeEventSource(source) {
+ Line 1559: function removeEventSource(sourceInput) {
+ Line 1560: var source = buildEventSource(sourceInput);
---

What this does is pass the array through the same function it is passed through when you add it. Otherwise, there is no way to compare the two arrays. Our application only uses array sources... but if you are mixing source types, you may want to do the conversion only if it is an array being passed:





-----fullcalendar.js--2.1.0-beta3-----
- (Line 1559 : 1578)
+ (Line 1559 : 1597)
-----fullcalendar.js--2.1.0-beta3-----

function removeEventSource(sourceInput) {
  if ($.isArray(sourceInput)) {
    var source = buildEventSource(sourceInput);
    sources = $.grep(sources, function(src) {
      return !isArraySourcesEqual(src, source);
    });
    cache = $.grep(cache, function(e) {
      return !isArraySourcesEqual(e.source, source);
    });
  } else {
    var source = sourceInput;
    sources = $.grep(sources, function(src) {
      return !isSourcesEqual(src, source);
    });
    cache = $.grep(cache, function(e) {
      return !isSourcesEqual(e.source, source);
    });
  }
  // remove all client events from that source		
  reportEvents(cache);
}

function isSourcesEqual(source1, source2) {
  return source1 && source2 && getSourcePrimitive(source1) == getSourcePrimitive(source2);
}

function getSourcePrimitive(source) {
  return ((typeof source == 'object') ? (source.events || source.url) : '') || source;
}

function isArraySourcesEqual(source1, source2) {
  return source1 && source2 && getArraySourcePrimitive(source1.events) == getArraySourcePrimitive(source2.events);	
}

function getArraySourcePrimitive(source) {
  for (var key in source) {
    return ((typeof source == 'object') ? (source[key].id || source[key].url) : '') || source;
  }
}

-----fullcalendar.js--2.1.0-beta3-----
- (Line 1559 : 1578)
+ (Line 1559 : 1597)
-----fullcalendar.js--2.1.0-beta3-----

So basically, to ensure this doesn't break other functionality if you need it, we only use the workaround if an array is being passed... otherwise, nothing changes. This should ensure we aren't robbing Peter to pay Paul with this workaround. Obviously there are still a number of issues with this quick workaround that make it less than production-ready: For one, the array comparison function is not ideal. Again, I will see what I can do to clean it up. We'll likely stick with 1.6.4 in production for now until either a fix is released or we decide to fork this entire project.

This project rocks - honestly one of the first times I've been even mildly frustrated in the years I've been using it. While almost every other open source project is slowing down fullcalendar is actually gaining momentum and that is awesome. If I end up having to fork it, I would likely just pull down the latest release each time and modify this one section of code.

Aug 27, 2014
#19 bhol...@snapappointments.com
Do we want to add the "skeleton" tag to this? This portion of the code appears to remain unmodified in the latest 2.1 final release and needs to be properly tagged in order to remain visible. This issue is preventing a number of people from upgrading from 1.6.4 and if this functionality is officially going to be eliminated in 2.0+ we might as well reject the issue so people stop waiting around for a fix. I can create a new fork of the project that restores this functionality in a more efficient manner than this workaround I have provided and go from there. There is enough addressed in the updates over the past few months that it seems crazy people are stuck using 1.6.4 because of 10 lines of code. Since 2.1 is out of beta and officially the final release, it appears compatibility with arrays are being left behind for good in exchange for a push toward multiple http requests (something that is an issue for larger projects like ours). We are using Socket.io to deliver an array of event sources simultaneously with real-time updates. 

Disappointed to see this wasn't addressed in 2.1 final as it breaks basic functionality that always existed before 2.0... but has now remained broken for months.
Aug 27, 2014
Project Member #20 adamrs...@gmail.com
I had bigger fish to fry with 2.1.0.

This is still on my radar, don't worry.
Aug 27, 2014
#21 bhol...@snapappointments.com
If any of you are still with us, I can confirm this issue remains untouched in 2.1 final. To resolve it using my same quick/dirty workaround, the instructions are the same (despite the line numbers changing). Simply delete lines 1565 - 1584 and replace with:

function removeEventSource(sourceInput) {
  if ($.isArray(sourceInput)) {
    var source = buildEventSource(sourceInput);
    sources = $.grep(sources, function(src) {
      return !isArraySourcesEqual(src, source);
    });
    cache = $.grep(cache, function(e) {
      return !isArraySourcesEqual(e.source, source);
    });
  } else {
    var source = sourceInput;
    sources = $.grep(sources, function(src) {
      return !isSourcesEqual(src, source);
    });
    cache = $.grep(cache, function(e) {
      return !isSourcesEqual(e.source, source);
    });
  }
  // remove all client events from that source		
  reportEvents(cache);
}

function isSourcesEqual(source1, source2) {
  return source1 && source2 && getSourcePrimitive(source1) == getSourcePrimitive(source2);
}

function getSourcePrimitive(source) {
  return ((typeof source == 'object') ? (source.events || source.url) : '') || source;
}

function isArraySourcesEqual(source1, source2) {
  return source1 && source2 && getArraySourcePrimitive(source1.events) == getArraySourcePrimitive(source2.events);	
}

function getArraySourcePrimitive(source) {
  for (var key in source) {
    return ((typeof source == 'object') ? (source[key].id || source[key].url) : '') || source;
  }
}

Again... not ideal but at least you will be able to remove array sources with this "fix". The issue is the same as it has been since 2.0 beta nearly 7 months ago - when array sources are added, they are being converted to objects. When you try to remove an array source, no conversion takes place and it is attempting to match an array to an object; no match is found... nothing is removed. If you use array sources in this manner, your options are to implement this fix or continue using 1.6.4 (the last release before this functionality was broken). Although extremely dated now, we have chosen to continue using 1.6.4 until we can have one of our developers fork fullcalendar and maintain the fork.
Aug 27, 2014
#22 bhol...@snapappointments.com
Adam:

Glad to hear it's still on the radar... and I have been getting a small taste of the level of communications you must be receiving on a daily basis. However, if this isn't something that will be added soon, just let me know so we can fork the project and go from there. Every time there is a new release, I'm now getting anywhere from 20-30 messages (between email, StackOverflow, etc) asking how to implement the workaround in the latest release. I feel bad because it wasn't even a well thought out workaround... and we are continuing to use 1.6.4 in production... but it gets the job done and I make sure to write everyone back. I guess by keeping it separate as I have at least it isn't stepping on any functionality. 

Obviously everybody thinks their issue is the most important... but now I feel like I'm in the trenches and have set a precedent to help people here. Just a general idea of a time frame would be greatly appreciated so I know which direction we need to go with this. This one issue has ended up becoming far too time consuming (magnified by your rapid progress and releases lately) and had I known it was low-priority when I posted it a couple months ago I would have forked it at that point and put one of our developers on the project.

Appreciate all of your hard work - frustrating... but I've been in your shoes and understand your priorities aren't always going to align with what others view as priorities. While I know of ~25 people affected by this issue, there are probably thousands who are unaffected and sometimes it's a numbers game.  
Aug 27, 2014
#23 fusionh...@gmail.com
My advice? Just forget it man. He hasn't tagged it with "skeleton" for a reason and that reason is that he doesn't really think this is a big deal. His vision differs from yours and it's his project. You reported the issue, he is aware of it - move on and check back in a year. Maybe it will be fixed someday maybe not - welcome to open source software. Besides, what functionality do you need that 2.1 has and 1.6 doesn't? We're using 1.6 in production also and it does everything we need. We tried 2.0, noticed this very issue, realized we didn't really need any of the new features, and went back to 1.6. When we saw 2.1 was released yesterday we went through the same process. Clearly 1.6 works for you and if it isn't broke, don't fix it. In your case, 2.1 is broke so even less of a reason to hassle with it. They are more focused on visual improvements such as "simplify styling of events in extern-draggable demo" and "change technique for spacing around events" and this says to me you and I are using fullcalendar differently than designed. They have their own set of goals! 1.6 is stable and it works. If/when the developer/team decides to fix this you'll get the notification and you can come check it out. Until then, just move on to something else. Sorry but this thread gave me a headache and that's coming from a guy that is having this exact issue. I just happened to handle it differently.
Aug 27, 2014
#24 bhol...@snapappointments.com
Understand your point, #23, but the fact remains that 2.1 does contain a number of features and fixes which would improve our service and make our lives easier. I think most people would agree this developer doesn't owe us anything and obviously it's his project but typically issues that break previously existing functionality take priority over visual tweaks and a lot of work has been done on this project since this issue was first reported. I don't feel entitled to anything but that doesn't mean I can't be frustrated that an issue I believe is high-priority is lower on their list than "simplify styling of events in extern-draggable demo." You make a good point - this isn't my project and that isn't my call to make - but you are mistaking my frustration for entitlement. This is a community-driven open source project and while I'm not making the calls or setting priority levels I speak for a number of people when I say this issue is important to us. I'd prefer not to let it die and miss out on taking advantage of some of the latest improvements all because of one easily-addressed issue. We'll have to agree to disagree, #23 - while I'm certainly trying to help myself I've taken a lot of time out of my busy schedule to assist a lot of people work around this issue (even if it isn't an ideal solution).
Aug 27, 2014
Project Member #25 adamrs...@gmail.com
Version 2.1 was all about refactoring the calendar's HTML/CSS skeleton (thus the tag "skeleton"). I drew the line at that. If the project is focusing on too many unrelated things, then it's easy to get overwhelmed and then nothing gets done.

I judge a ticket's demand by the # of stars it has. This ticket currently has 6. It is 1.5 months old.

The cumulative # of stars of closed issues related to the skeleton refactor was *267*. And some of those issues were 5 years old.

Going by stars, relative to other tickets, this one doesn't seem to affect that many people. Maybe just a vocal minority. Or maybe a lot of people who don't know about the "star" system. Or they are communicating on other places like StackOverflow (thanks for letting me know @bholzer and thanks for helping those people out).

@fusionhash, some of your points are valid, but in general, please cheer up. All the commits you see were important, for some reason or another, to the skeleton refactor.

Regardless of any of this, I was planning on waiting a few days to see if there were any bugs related to the 2.1 release. I would then release this fix with that (2.1.1)

The ironic thing is that I could have fixed this bug in the time it took me to write this response :(
Aug 28, 2014
#27 bhol...@snapappointments.com
Thank you - simple, graceful solution that appears to be working flawlessly. I sent another small donation your way for being such a pain and certainly intend to contribute more down the road for all you do when I can. You have put a ton of hard work into this project over the years.   
Aug 29, 2014
Project Member #28 adamrs...@gmail.com
released:
https://github.com/arshaw/fullcalendar/releases/tag/v2.1.1
Status: Released
Sep 29, 2014
#29 martijn....@gmail.com
Thanx for this fix!
Nov 3, 2015
#30 f.glog...@gmail.com
Hello!
I still had the issue that I couldn't delete an array of events with "removeEventSource". The problem is, that the code in the following code in function "isSourcesEqual" can't compare the arrays that it is given.

getSourcePrimitive(source1) == getSourcePrimitive(source2)

To solve the problem, I changed the function to the following:

function isSourcesEqual(source1, source2) {
    var primitive1 = getSourcePrimitive(source1);
    var primitive2 = getSourcePrimitive(source2);
    if ($.isArray(primitive1)){
      if (primitive1.length != primitive2.length){
        return false
      }
      for(x = 0; x<primitive1.length; x++){
        if (primitive1[x].id != primitive2[x].id){
          return false
        }
      }
      return true;
    }
    return source1 && source2 && primitive1 == primitive2;
  }

I hope it helps!
Cheers, Freddy
Sign in to add a comment

Powered by Google Project Hosting