FLUID-6226: Nested usage of fluid.generate results in odd behavior...

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
  1. 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.