{"action":"opened","issue":{"url":"https://api.github.com/repos/facebook/immutable-js/issues/828","repository_url":"https://api.github.com/repos/facebook/immutable-js","labels_url":"https://api.github.com/repos/facebook/immutable-js/issues/828/labels{/name}","comments_url":"https://api.github.com/repos/facebook/immutable-js/issues/828/comments","events_url":"https://api.github.com/repos/facebook/immutable-js/issues/828/events","html_url":"https://github.com/facebook/immutable-js/issues/828","id":147462864,"number":828,"title":"Add touch (clone) method back into immutable.js.","user":{"login":"jamespedid","id":1280555,"avatar_url":"https://avatars.githubusercontent.com/u/1280555?v=3","gravatar_id":"","url":"https://api.github.com/users/jamespedid","html_url":"https://github.com/jamespedid","followers_url":"https://api.github.com/users/jamespedid/followers","following_url":"https://api.github.com/users/jamespedid/following{/other_user}","gists_url":"https://api.github.com/users/jamespedid/gists{/gist_id}","starred_url":"https://api.github.com/users/jamespedid/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jamespedid/subscriptions","organizations_url":"https://api.github.com/users/jamespedid/orgs","repos_url":"https://api.github.com/users/jamespedid/repos","events_url":"https://api.github.com/users/jamespedid/events{/privacy}","received_events_url":"https://api.github.com/users/jamespedid/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-04-11T15:22:35Z","updated_at":"2016-04-11T15:22:35Z","closed_at":null,"body":"Let me preface this by saying that clone was removed in a previous version, and this essentially is the same function as clone. However, I'm going to provide a simple use case and argument why this function should exist.\r\n\r\nFor immutable objects, one might think that the 'state' of an object is frozen. Normally, when people think of this, they think that the properties of the immutable object are frozen. However, I tend to think a little bit beyond that fact and I also like to think that the point in time that the object was created at is also captured in an immutable object as well. That is, I view two immutable objects with identical properties as being frozen that are created at two different times to be different. Of course, this is a different definition of immutable objects as given here.\r\n\r\nOf course, there are consequences to the above that may make certain usages of immutable objects harder to work with: I mean, there are definitely cases where you want to have two immutable objects as being declared as equal even if they are created at two different points in time; this is totally correct. I'm not looking to change this aspect of immutable objects.\r\n\r\nHowever, I'm looking for the alternative to declare that I want a new immutable object with the same properties at a different time. In this sense, I'm declaring that the immutable object has changed, namely the timestamp when the immutable object is considered up to date.\r\n\r\nHaving a touch method (equivalently clone) allows me to do just this. I'm finding it incredibly difficult to replicate this functionality otherwise, and since there are no formal timestamp properties of immutable objects (to my knowledge), I'm unable to declare an operation that notifies that an immutable object is up-to-date, and refresh the objects.\r\n\r\nThe use case here is to have a react-redux component update when the element changes. This use case is arising from the fact that I'm storing objects in certain locations of an immutable JS object that fundamentally cannot be immutable (they are ES6 class objects, and aren't fundamentally data; this might be a violation of immutable's philosophy, but sometimes these design decisions have to be made). I want a way of notifying the store that the object has been updated, based solely on when I consider the object to be up-to-date, and this can be independent of the standard equality operation on immutable objects.\r\n\r\nI can understand thinking that clone has no place in an immutable API, and in some regards maybe it doesn't, but at least consider this use case."}}