How to solve: Don't use Object as a type.....

[rsoika]

Hi,

I try to adapt the jsonforms-property-view in my own project. But I struggle with a lot of typescript errors.

When I try to build my project with yarn I got a lot of messages like this ones:

36:26  error    Don't use `Object` as a type. The `Object` type actually means "any non-nullish value", so it is marginally better than `unknown`.

such message result from code like this:

import { ModelServerClient } from '@eclipse-emfcloud/modelserver-theia';

export async function getElementFromModelServer(modelServerClient: ModelServerClient, modelUri: string, elementId: string): Promise<Object> {
    return modelServerClient.getElementById(modelUri, elementId, 'json')
......

where Promise<Object> is to problematic source code.

I am not the JavaScript expert. I am using lint, eslint and tsconfig.json like recommended in the GLSP examples.

Can someone help me solve this compiler issue. Should I rewrite the code or is there a way to 'ignore' this errors?

I already have tried to adapt the following tsconfig.json from the jsonforms-property-view project, but with no better result:

{
  "extends": "@eclipse-glsp/ts-config/tsconfig.json",
  "compilerOptions": {
    "rootDir": "src",
    "outDir": "lib",
    "baseUrl": ".",
    "noImplicitAny": false,
    "types": [],
    "skipLibCheck": true,
    "declaration": true,
    "declarationMap": true,
    "noEmitOnError": false,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "noImplicitReturns": true,
    "strictNullChecks": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "downlevelIteration": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "target": "ES2017",
    "jsx": "react",
    "lib": [
      "ES2017",
      "dom"
    ]    
  },
  "include": ["src"]
}

I am thankful for any help.

[ndoschek]

Hi @rsoika,
You can use to the non-primitive object type (which was added in Typescript 2.2) instead.
This is most likely an issue due to Typescript and ESLint versions. It is also listed in the Typescript Do's and Don'ts
And you are right, it is confusing and we should change that on our side as well. I will create an issue for that!

[ndoschek]

Hi @rsoika,
I'm not exactly sure why this issue appears on your side (do your Typescript and/or ESLint versions differ?), but it seems to be an ESLint issue, as it was an stylistic design decision on their side.
You could disable the rule in your ESLint config: via "@typescript-eslint/ban-types": "off" or try Record<string, unknown> instead of Object as described in the previous mentioned link.

[tortmayr]

For the emfcloud-modelserver-theia project we introduced a AnyObject helper type that can be used as replacement for object or Object. (https://github.com/eclipse-emfcloud/emfcloud-modelserver-theia/blob/ccd36ac2d75ba6f4cc0f1ad48c80d9e026ca5278/packages/modelserver-client/src/utils/type-util.ts#L19)
You could use a similar construct in your project. But as @ndoschek already mentioned I think it's also more than fine to just disable the rule in question via ESLint config.

[rsoika]

Thanks for your help.
Working with my own new class AnyObject helped me to get the compiler issues solved.
But still I am unable to integrate the ModelServerPropertyDataService and ModelserverAwareWidgetProvider from the ecore example

I can not use the same dependencies like in the example https://github.com/eclipse-emfcloud/ecore-glsp/blob/3f0d45204371d4aaef0f43bd8cdcf2c6b2bda082/client/packages/ecore-property-view/package.json#L13

I have than more and more conflicts with my existing dependencies. Or I got compiling errors like

Property 'body' does not exist on type 'string'.

71                 const typeSchema = response.body as JsonSchema7;

or that the methods onAttach / onDetach did not exist from code lines like this:

        this.jsonFormsWidget.onAttach(() => this.doSubscribe());
        this.jsonFormsWidget.onDetach(() => this.doUnsubscribe());

I can play around with the dependency versions to get my project compiled (much guessing). But than my application is no longer working at all.
It looks like the ecore code is not running with @eclipse-glsp/client": "0.9.0 which is currently my base.

When I use the following dependencies in my PropertyView module:

  "dependencies": {
    "@eclipse-emfcloud/modelserver-theia": "0.8.0-next.6b3138d6",
    "@eclipse-emfcloud/modelserver-jsonforms-property-view": "0.8.0-next.c8999361",
    "@eclipse-emfcloud/jsonforms-property-view": "0.8.0-next.c8999361",
    "@eclipse-emfcloud/theia-tree-editor": "0.7.0-next.0324b32",
    "@eclipse-glsp/client": "0.9.0-next.ab8b59c9",
    "@eclipse-glsp/protocol": "0.9.0-next.ab8b59c9",
    "@eclipse-glsp/theia-integration": "0.9.0-next.f4750f16",
    "@theia/core": "^1.0.0",
    "@theia/property-view": "^1.0.0",
    "@theia/workspace": "^1.0.0"
  },

I got a conflict in my client-glsp module

src/di.config.ts(37,10): error TS2305: Module '"@eclipse-glsp/protocol"' has no exported member 'DefaultTypes'.

And when I adjust the @eclipse-glsp/client and @eclipse-glsp/protocol to version 0.9.0 than my application is no longer starting and I got the following strange error message:

.....
$ yarn rebuild:browser && yarn --cwd open-bpmn-app start
$ theia rebuild:browser
native node modules are already rebuilt for browser
$ theia start --GLSP_PORT=5007 --root-dir=../workspace
root ERROR Uncaught Exception:  TypeError: Cannot read property 'hostname' of undefined
root ERROR TypeError: Cannot read property 'hostname' of undefined
    at DefaultModelServerClient.prepareBaseUrl (/home/rsoika/git/open-bpmn/open-bpmn.glsp-client/node_modules/@eclipse-emfcloud/modelserver-theia/lib/node/model-server-client.js:78:49)
.....

I guess the ecore property view is not a good starting point for me to learn how property views work :-(

[ndoschek]

Hi @rsoika,
As mentioned in the previous dicussion I moved your questions regarding the adptation of the JsonForms property view to a separate discussion: #126 and provided a short guideline there.
Could you please take a look if that helps you, thanks!
I will close this discussion, as your initial typescript issues were resolved.

[rsoika]

Yes I will do so. Sorry, excuse me for losing focus on this question. The question was answered perfectly with the suggestion to use AnyObject instead of Object.