Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    TypeScript support

    Hello, after the very good work by MrHighTech about TypeScript integration, I'm very interested in the TypeScript support for the upcoming release of SmartClient 12:
    http://blog.isomorphic.com/5-more-re...12-0-features/

    Considering a typical snippet of code as:
    Code:
    isc.ListGrid.create({
      ID: "myGrid",
      ....
    });
    I think that it would be useful if the IDE could 'recognize' myGrid as a variable of type ListGrid, so that type checking, refactoring, code completion... would become available for it.

    I'm currently using Intellij, but I don't know if this is feasible. Would it require an IDE plugin?

    #2
    Hello, about the previous question: is there something wrong if I write code like that
    Code:
    let myGrid: isc.ListGrid = isc.ListGrid.create({
      ID: "myGrid",
      ....
    });
    so that I can have autocompletion on myGrid and also have myGrid as the ID of the SmartClient object?

    Comment


      #3
      Hello, I'm trying the TypeScript support in the latest 12 release, very nice.

      I see that ListGrid.fields is an array of ListGridField, so if I write:
      Code:
      let myGrid: isc.ListGrid = isc.ListGrid.create({
        ID: "myGrid",
        fields:[
          {name:"foo", type:"text"}
        ]
      });
      Intellij marks that as an error (even if it compiles the js file)

      Otherwise I have to use defaultFields. Is it safe? I recall a warning when using it outside of a subclass of ListGrid, but I don't see it anymore.

      Also, in both cases, using an object literal as field definition (which BTW is the best style for readability) has the defect of not having autocomplete for the ListGridField attributes.
      Is it available an alternative approach?

      Some showcase samples written in TypeScript would be useful.

      Comment


        #4
        Originally posted by claudiobosticco View Post
        Hello, about the previous question: is there something wrong if I write code like that
        Code:
        let myGrid: isc.ListGrid = isc.ListGrid.create({
        ID: "myGrid",
        ....
        });
        so that I can have autocompletion on myGrid and also have myGrid as the ID of the SmartClient object?
        That would work. Or slightly more compact:

        Code:
        let myGrid = isc.ListGrid.create({
            ID: "myGrid",
        ...
        });
        ...would definitely get you auto-completion. Your assessment of the ID property propagation is accurate - that would require a plugin per-IDE, which we are unlikely to pursue at present. And it's not even clear if a plugin could achieve what we would want here because TypeScript doesn't appear to do full codepath analysis to fixate types. Consider the following example:

        Code:
        let s = "foo";
        s = s.toLowerCase();
        window["bar"] = s;
        bar = bar.toUpperCase();
        In VisualStudio, for example, the reference to bar produces an error for both the LHS and RHS of the expression because the compiler isn't smart enough to figure out either that the assignment on the previous line constitutes a global binding or that the binding is of type string. Given this, it's not clear how we could make TypeScript aware of a new global dynamically.

        One wrinkle to keep in mind: although it looks redundant to specify "myGrid" as both the variable name and ID, there is a slight variance in downstream code. While both result in a global identifier, the ID property is also used to generate various properties, some of which percolate to developer-visible artifacts - for example: scLocators (used for automated testing).

        Comment


          #5
          Originally posted by claudiobosticco View Post
          Hello, I'm trying the TypeScript support in the latest 12 release, very nice.

          I see that ListGrid.fields is an array of ListGridField, so if I write:
          Code:
          let myGrid: isc.ListGrid = isc.ListGrid.create({
          ID: "myGrid",
          fields:[
          {name:"foo", type:"text"}
          ]
          });
          Intellij marks that as an error (even if it compiles the js file)

          Otherwise I have to use defaultFields. Is it safe? I recall a warning when using it outside of a subclass of ListGrid, but I don't see it anymore.

          Also, in both cases, using an object literal as field definition (which BTW is the best style for readability) has the defect of not having autocomplete for the ListGridField attributes.
          Is it available an alternative approach?

          Some showcase samples written in TypeScript would be useful.
          Yes, defaultFields are perfectly safe to use - the difference is simply that defaultFields are cloned into fields at init time. This is slower, but resolves the situation where a single object literal is being passed around as a constructor for multiple components.

          But, getting back to the TypeScript issue. In the next stable build (March 31, 2018 onward), both defaultFields and fields will resolve to a <Partial<ListGridField>> spec which will allow you to specify supported properties in the standard fashion. Because of some internal data type munging, defaultFields were resolving to a type 'any' whereas fields were resolving to ListGridField - hence the delta. But both should (and will) support a partial ListGridField spec instead.

          Comment


            #6
            Thank you very much, I'm waiting for the next build to try it out.

            Comment


              #7
              SmartClient Version: SNAPSHOT_v12.1d_2018-04-03/EVAL Development Only (expires 2018.06.02_07.21.09) Licensed to: Isomorphic Software (#ISC_EVAL_NIGHTLY)

              Thanks, now both ListGrid.defaultFields and fields work.

              But I've got another error which I can't explain: Intellij marks an error if I define the click method on an IButton, a Button or a StatefulCanvas.

              Comment


                #8
                Another kind of limitation which I don't know if may be improved: if I define a form:
                Code:
                isc.DynamicForm.create({
                  ID: "foo",
                  fields:[
                    {
                       name:"bar",
                       type: "button",
                       icon: "myIcon.png"
                ........
                the icon attribute is marked as an error, because a FormItem doesn't have it. The same is true for many other attributes of SelectItem, ComboboxItem, etc...

                Comment

                Working...
                X