search

SAP / ui5-typescript

Tooling to enable TypeScript support in SAPUI5/OpenUI5 projects
https://sap.github.io/ui5-typescript
Apache License 2.0
200 stars 28 forks source link

Please check working TS alternatives / babel plugin #15

Closed promosjotte closed 4 years ago

promosjotte commented 5 years ago

Hey Guys,

please consider to provide an official babel plugin. There is already a really good working way with typescript using the following babel plugin: https://github.com/r-murphy/babel-plugin-transform-modules-ui5/blob/master/README.md

It can be combined with the JSX plugin (https://github.com/serban-petrescu/ui5-jsx-rm). This makes UI5-devs very happy ;)

My pipeline works with all VS-Code features which makes programming UI5 much more easy and productive.

Bye.

bd82 commented 5 years ago

An official Babel plugin is beyond the immediate scope of this project. Perhaps colleagues from UI5 have some feedback: @codeworrior @petermuessig ?

Regardless It does raise the issue that the current TypeScript signatures are exposed as globals So if it is possible to use ECMAScript import/export syntax with UI5 then the signatures may need to be provided as UMD signatures so they would be compatible with the import/export syntax.

bd82 commented 5 years ago

I have been thinking of this again and I am not sure how this would work. @promosjotte

For the discussion: assume you have types signatures on each OpenUI5 npm packages. What ES6 import syntax would you use to import sap/m/button from @openui5/sap.m package. and would that Babel plugin know how to translate it to sap.ui.define syntax?

// We can only import an Identifier
// But we need to import a deeply nested FQN (e.g: sap.m.Button)
// So how would this work?
import {X} from "@openui5/sap.m"
Mischa1610 commented 5 years ago

From a view of a „TypeScript“ developer it would be really awesome to have following (and maybe more) possibilities and „officially“ supported by SAP:

(Maybe also a topic for the ui5-tooling)

bd82 commented 5 years ago

@Mischa1610 These are both great suggestions, but are however well outside the scope of this (UI5-TypeScript) project.

Perhaps @codeworrior and @petermuessig from UI5 would like to comment on this?

Mischa1610 commented 5 years ago

@bd82 I understand your point. Would be awesome if developers from UI5 could answer regarding this topic or point me to a repo/issue where it would be more appropriated to talk about this topic.

petermuessig commented 5 years ago

Hi @Mischa1610 ,

yes, I can agree, that it would be awesome to come closer towards the latest Web Standards with the UI5 programming model. While we are doing this for the UI5 Web Components, for UI5 we are modernizing the code base as fast as we can but also with the limitation to stay compatible and safe the investments for existing applications. This is our biggest challenge. But it doesn't mean necessarily to not use the latest features - but it might require a transpiling step.

For ES modules the best option for now is to use the transpiling as you mentioned above. From my POV this doesn't need to come from SAP. I personally like that some kind of an ecosystem is growing that other people show how to leverage OSS tools to come to a modern development experience. But I take your feedback into account we might consider this in future.

Some more background: for the code base of UI5 it is pretty hard to go to ES modules as this would completely kill the compatibility - AMD and ES modules are not even feature-parity, AMD (and the subset we use in the UI5 AMD-like syntax) allows us to hide some nice optimizations behind it. In UI5 Web Components we learned that building a framework with ES modules you need to re-think the way of using dependencies much more - also in ES modules the dynamic import is not yet well supported in all modern browsers and this is heavily used in UI5 but not for the UI5 Web Components. But we have in mind to come to ES modules in the future but it is unclear yet how this would look like and how we can do this in a compatible way. Maybe with the support of dynamic imports in all browsers this might be possible to still use UI5s AMD-like APIs and use the dynamic imports behind.

Regarding the class syntax: here we are not that far away from making this possible. @codeworrior has implemented a little POC which allows to use the class syntax instead of the .extend call. This might be also possible to be added sooner or later - we are investigating this option already. Maybe we can share some details on this soon.

Thanks for your input. This is highly appreciated. :-)

Best regards, Peter

htammen commented 5 years ago

Hi all, I'm currently developing 5 UI5 applications in parallel with typescript. I use typescript classes instead of extend. Cause these projects are customer projects I can't reveal the code. Therefore I plan to write a blog with a little example project. But unfortunately I don't find the time to do so. Basically it's a matter of writing a constructor that binds the UI5 metadata to the class. To enable typescript to recognize my classes I create a .d.ts definition file in which I define my classes. In this file I primarily define my BaseController, ComponentController and my own data classes (in these projects I'm using JSONModel). This is a bit of double work but it's worth the effort. There are still some things that are not perfectly supported going this way, e.g. I haven't found a way to use enums without coding them two times (in d.ts and my ts files) and I have to use verbose fqn for my classes. But nevertheless it's working very well for me, I feel much more comfortable with my code and coding with code intellisense makes life easier.

Mischa1610 commented 5 years ago

Hi @petermuessig,

thanks a lot for the quick response, the informations and insight you gave, really appreciate it.

I totally understand (and think it is a good approach) to modernize the code base of UI5 and still be backwards compatible.

For the UI5 Web Components you guys could start from scratch and that made it possible to use the latest Web Standards and good that you did it (if I saw it correct you guys used litHtml for rendering and than defined own "BaseComponent" that can/should be extended. Was it possible to reuse some code from UI5 (the framework)? (I think only the styles, .less files were maybe possible, otherwise you basically used Fiori as a Design System definitions and implemented the Controls/Components in this way, correct?) Just as a side note to UI5 Web Components 😄

In general a transpiling step is totally fine, a lot other frameworks do it. The difference is that the give a start/setup that has this already included. I totally agree with you that it is good to have a ecosystem that is growing around the framework, but it would help a lot if there could be documentations, informations or recommendations from SAP, because than it would be way easier to add this possibilities and also suggest ("defend") this (for example to customers).

Thank you for the background informations that you shared, that gave me more insight in the "problems" and helped to understand it more.

Would be awesome if you could share details soon on the Class "vs." .extend topic, do you know (or @codeworrior) where you would share this informations?

Best regards, Michael

Hi @Mischa1610 ,

yes, I can agree, that it would be awesome to come closer towards the latest Web Standards with the UI5 programming model. While we are doing this for the UI5 Web Components, for UI5 we are modernizing the code base as fast as we can but also with the limitation to stay compatible and safe the investments for existing applications. This is our biggest challenge. But it doesn't mean necessarily to not use the latest features - but it might require a transpiling step.

For ES modules the best option for now is to use the transpiling as you mentioned above. From my POV this doesn't need to come from SAP. I personally like that some kind of an ecosystem is growing that other people show how to leverage OSS tools to come to a modern development experience. But I take your feedback into account we might consider this in future.

Some more background: for the code base of UI5 it is pretty hard to go to ES modules as this would completely kill the compatibility - AMD and ES modules are not even feature-parity, AMD (and the subset we use in the UI5 AMD-like syntax) allows us to hide some nice optimizations behind it. In UI5 Web Components we learned that building a framework with ES modules you need to re-think the way of using dependencies much more - also in ES modules the dynamic import is not yet well supported in all modern browsers and this is heavily used in UI5 but not for the UI5 Web Components. But we have in mind to come to ES modules in the future but it is unclear yet how this would look like and how we can do this in a compatible way. Maybe with the support of dynamic imports in all browsers this might be possible to still use UI5s AMD-like APIs and use the dynamic imports behind.

Regarding the class syntax: here we are not that far away from making this possible. @codeworrior has implemented a little POC which allows to use the class syntax instead of the .extend call. This might be also possible to be added sooner or later - we are investigating this option already. Maybe we can share some details on this soon.

Thanks for your input. This is highly appreciated. :-)

Best regards, Peter

htammen commented 5 years ago

As I mentioned last sunday I don't have time to write a blog about my current typescript projects. But I managed to upload a few gists to github. Hope they are helpful. tsconfi.json: https://gist.github.com/htammen/165f89b0dcdfb3ac6d2dc71c24319f10 Component controller: https://gist.github.com/htammen/ded10c88ee2d6d51b56a27f6b4f1ae93 Base view controller: https://gist.github.com/htammen/c9e5167570fa88cd436d5aa72dd1c512 View controller: https://gist.github.com/htammen/2b10f3c7c907ac4096b0683e49435a8d Type definitions: https://gist.github.com/htammen/e2a3eb56261de0010876c6c3105f360f package.json: https://gist.github.com/htammen/b962211eaa33bac8ed8cb27bdde8c5f8

bd82 commented 4 years ago

Closing this as this discussion seem to have reached in end.