[tree view] `apiRef` type is `Partial<{}>` which causes Typescript compilation to fail

[Shenloo]

Steps to reproduce

Link to live example: https://codesandbox.io/p/sandbox/infallible-nightingale-8h29cd?file=%2Fsrc%2FDemo.tsx%3A35%2C3

Steps:

1. In Demo.tsx line 50, apiRef has type React.MutableRefObject<Partial<{}> | undefined>

Current behavior

Typescript compilation fails with errors: "Property 'getItem' does not exist on type 'Partial<{}>'.", "Property 'getItemDOMElement' does not exist on type 'Partial<{}>'.". This is the sample use case of getItem in code: "const item = apiRef.current!.getItem(itemId);". This happens also when apiRef.current is explicitly checked for being defined (e.g. const item = apiRef.current ? apiRef.current!.getItem(itemId) : null;).

Expected behavior

apiRef is properly typed, and there are no errors during compilation.

Context

No response

Your environment

npx @mui/envinfo

``` System: OS: Linux 6.5 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish) Binaries: Node: 20.10.0 - ~/.nvm/versions/node/v20.10.0/bin/node npm: 10.2.3 - ~/.nvm/versions/node/v20.10.0/bin/npm pnpm: Not Found Browsers: Chrome: Not Found npmPackages: @emotion/react: ^11.13.0 => 11.13.0 @emotion/styled: ^11.13.0 => 11.13.0 @mui/base: 5.0.0-alpha.122 @mui/core-downloads-tracker: 5.16.7 @mui/icons-material: ^5.11.11 => 5.11.16 @mui/material: ^5.16.7 => 5.16.7 @mui/private-theming: 5.16.6 @mui/styled-engine: 5.16.6 @mui/system: 5.16.7 @mui/types: 7.2.15 @mui/utils: ^5.15.7 => 5.16.6 @mui/x-data-grid: latest => 6.9.0 @mui/x-date-pickers: ^6.3.0 => 6.3.0 @mui/x-internals: 7.12.0 @mui/x-tree-view: ^7.12.1 => 7.12.1 @types/react: ^18.0.28 => 18.0.28 react: 18.2.0 => 18.2.0 react-dom: 18.2.0 => 18.2.0 typescript: ^4.9.5 => 4.9.5 ```

tsconfig

``` { "compilerOptions": { "strict": true, "allowUnreachableCode": false, "exactOptionalPropertyTypes": false, "noImplicitReturns": true, "noUnusedParameters": true, "noUnusedLocals": true, "noPropertyAccessFromIndexSignature": true, "skipLibCheck": true, "allowJs": true, "baseUrl": "src", "paths": { "@/*": ["./*"] }, "jsx": "preserve", "lib": ["DOM", "DOM.Iterable", "ESNext", "WebWorker"], "module": "ESNext", "moduleResolution": "Node", "noEmit": true, "preserveConstEnums": true, "resolveJsonModule": true, "target": "ESNext", "sourceMap": true, "allowSyntheticDefaultImports": true, "esModuleInterop": true, "isolatedModules": true, "forceConsistentCasingInFileNames": true, "useDefineForClassFields": true, "incremental": true, "types": ["node", "jest", "@testing-library/jest-dom"], "plugins": [{ "name": "typescript-plugin-css-modules" }] }, "include": ["**/*.ts", "**/*.tsx", "next.config.js", "next-env.d.ts", "global.d.ts"], "exclude": ["node_modules"] } ```

Search keywords: useTreeViewApiRef, apiRef, getItem

[michelengelen]

This seems to come from the type MergeSignatureProperty, which has a default of {}.

https://github.com/mui/mui-x/blob/c0b599300f01c54a96a4443a6296b10c6555036d/packages/x-tree-view/src/internals/models/helpers.ts#L25-L32

It does resolve correctly on my local machine, so I wouldn't guess that this is a bug per se. Also CSB always has been a bit wonky with type resolution. We heavily use generic types in the tree view so maybe it has problems to resolve that 🤷🏼

The stackblitz demo for this does not have that problem!

@flaviendelangle any suggestions?

[flaviendelangle]

I'll have a look, hopefully it's just a small error on our side and not some weaknesses in how CSB handles TS :grimacing:

[flaviendelangle]

@michelengelen, do you still have the error in this example

I just added an explicit typing to the return value of useTreeViewApiRef and for me the error goes away. Which is weird... because it does not skip most of the Typing complexity... the MergeSignatureProperty is still needed.

[michelengelen]

@flaviendelangle yes, it still shows that error

[dominikmlynarczyk]

@flaviendelangle actually we are currently blocked by the same issue in our project. We are currently overriding .d.ts interface definitions, just to resolve the issue for now and push it to prod. Is there any ETA when you will provide proper type / implementation fixes for this issue?

Thanks a lot for your contribution! 💪

[flaviendelangle]

If you are able to reproduce this issue in a small repo outside of Codesandbox it would help me a lot :pray: