[codemod] Rename shouldDisableTime prop

[alexfauquette]

Part of #6997

[mui-bot]

	Messages
📖	Netlify deploy preview: https://deploy-preview-7709--material-ui-x.netlify.app/

These are the results for the performance tests:

Test case	Unit	Min	Max	Median	Mean	σ
Filter 100k rows	ms	714.4	1,192.3	714.4	936.64	185.817
Sort 100k rows	ms	739.2	1,423.9	1,423.9	1,073.82	230.221
Select 100k rows	ms	263	414.3	305.1	323.8	50.84
Deselect 100k rows	ms	166.6	415.5	196.2	252.22	91.495

Generated by 🚫 dangerJS against b7d6b94

[LukasTy]

Looks great! 💯
Just a general question: do you know if such thing is feasible with jscodeshift:
Having:

const props = {
  shouldDisableTime: (timeValue, view) => view === 'hours' && timeValue < 12,
};

<TimePicker {...props} />

transform it into:

const props = {
  shouldDisableClock: (timeValue, view) => view === 'hours' && timeValue < 12,
};

<TimePicker {...props} />

Because our current codemods will only cover users directly using pickers from our package as well as specifying props directly on the component, but I fear that in the real world we might have quite a lot of users doing the following:

• having a wrapper component on top of ours with additional logic/defaults
• spreading the props from some other object onto the picker component

[alexfauquette]

@LukasTy I don't think it's feasible with jscodeshift because we use AST which represent the code as tokens, but do not set any logic between them.

For example here is a simple code and it's associated AST in JSON (I removed most of the useless parts)

const prop = { label: "Name" }
<A {...props} />

{
  "program": {
    "type": "Program",
    "body": [
      {
        "type": "VariableDeclaration",
        "declarations": [
          {
            "type": "VariableDeclarator",
            "id": {
              "type": "Identifier",
              "name": "props"
            },
            "init": {
              "type": "ObjectExpression",
              "properties": [
                {
                  "type": "Property",
                  "key": {
                    "type": "Identifier",
                    "name": "label"
                  },
                  "computed": false,
                  "value": {
                    "type": "Literal",
                    "value": "Nale",
                    "raw": "'Name'"
                  },
                  "kind": "init",
                  "method": false,
                  "shorthand": false
                }
              ]
            }
          }
        ],
        "kind": "const"
      },
      {
        "type": "ExpressionStatement",
        "expression": {
          "type": "JSXElement",
          "openingElement": {
            "type": "JSXOpeningElement",
            "name": {
              "type": "JSXIdentifier",
              "name": "A"
            },
            "selfClosing": true,
            "attributes": [
              {
                "type": "JSXSpreadAttribute",
                "argument": {
                  "type": "Identifier",
                  "name": "props"
                }
              }
            ]
          },
          "children": [],
          "closingElement": null
        }
      }
    ]
  }
}

The tree is made of two parts:

• type: "VariableDeclaration" which declares the definition of props
• type: "ExpressionStatement" that defines the components

The only way to get the link between them is to notice that the first one defines an object of type "Identifier" with the name "props" which has the same name as the one used in the spread operator.

As you can imagine, this can not scale since you would have to consider all the possible ways to edit an object. Same if objects are imported (we only parse one file at a time)

[LukasTy]

@alexfauquette Thank you for a detailed answer. 🙏