Metadata
- Source
- FLUID-6226
- Type
- Task
- Priority
- Major
- Status
- Open
- Resolution
- N/A
- Assignee
- Antranig Basman
- Reporter
- Tony Atkins [RtF]
- Created
2017-11-17T15:46:38.600-0500 - Updated
2024-07-22T09:00:48.102-0400 - Versions
- N/A
- Fixed Versions
- N/A
- Component
-
- Framework
Description
While working on a problem that required an array of arrays, I discovered an unexpected behaviour when using fluid.generate in a nested fashion:
var grid = fluid.generate(2, fluid.generate(2, {}));
grid[0][0]= { set: true}; // grid[0][0] AND grid[0][1] are now set!
It seems like each "row" is a copy. If I pass the output the nested fluid.generate call would presumably generate, it works fine:
var grid = fluid.generate(2, [{}, {}]);
grid[0][0]= { set: true};
// grid[0][0] = {set: true}
// grid[0][1] = {}
If I assign the output to a function, it also works:
var nested = fluid.generate(2, {});
var grid = fluid.generate(2, nested);
grid[0][0]={set:true}
// grid[0][0] = {set: true}
// grid[0][1] = {}
Comments
-
Antranig Basman commented
2017-11-17T17:40:10.121-0500 Hi - thanks for this report. This is really a documentation issue - we should make clear that fluid.generate will make no attempt to clone its arguments if they are complex structures. There is a function-call form of fluid.generate which is intended for use where there is any intended subtlety in the use of non-primitive values - since, for example, the unilateral choice of fluid.copy() may not be appropriate for all users.
In your first example, you have supplied distinct objects {} and {} as the successive members of the top-level array, so naturally these remain distinct.
In your second example, you have misobserved the result, since you have had the array indices the wrong way round in all your tests (including the first comment) - it is in fact grid[1][0] which becomes polluted with the result {set: true}, not grid[0][1]. So there is no inconsistency of operation, just a poor explanation of the semantic of the function, which we should fix in infusion-docs.
-
Tony Atkins [RtF] commented
2017-11-20T03:26:31.477-0500 Thanks for spotting the error, there is indeed no difference between assigning a variable and passing the function call as the second argument to the top fluid.generate call.
I agree that documenting the behaviour is fine for now. If we come up with more use cases for this, we can talk about adding a "copy" flag that defaults to false.