NathanaelA / nativescript-dom

NativeScript DOM emulation methods
MIT License
42 stars 23 forks source link

class methods don't work with NativeScript 3.0 #8

Closed ludwiktrammer closed 7 years ago

ludwiktrammer commented 7 years ago

I try to port a project to the current RC version of NativeScript 3. All the methods on View.classList (like myView.classList.add("new-class");) seem to fail silently - i.e. there is no exception, but also the code has no effect.

ludwiktrammer commented 7 years ago

Also, sometimes (but not always) when using getElementsByClassName I get a TypeError: cannot read property 'contains' of undefined pointing to this line (which also comes back to classLiast).

NathanaelA commented 7 years ago

@ludwiktrammer - Very very very few plugins are NativeScript 3.0 compatible yet. In fact I don't know of any yet that have been released.

At this moment; if you want to use plugins you have to use NativeScript 2.5.

ludwiktrammer commented 7 years ago

That's not my experience. In the project I use nativescript-dom, nativescript-fresco, nativescript-dev-typescript and nativescript-dev-sass. Everything besides nativescript-dom works with NativeScript 3 RC - nativescript-dev-sass created the NS 3 compatibility update on April 1st and released the version containing it on April 6th. nativescript-fresco also created the update on April 1st and released the version just yesterday. I haven't checked the plugins that I'm not personally using, but I think in general plugin authors are using the RC version to test their plugins and get ready, so when the stable version comes out later this month, everything just works.

From the subjective perspective of my project nativescript-dom is the only holdout. You provide the plugin for free, so I'm fully aware you have no obligations when it comes to updating the plugin. I just wanted to create the ticket, so you are aware of the issue, and the plugin hopefully gets updated before the NativeScript 3 stable comes out. It seems to me important that nativescript-dom keeps up with NativeScript, since almost everyone seems to be using it, and NativeScript explicitly cites its existence as the reason why the functionality is not provided in NS core (as we discussed).

NathanaelA commented 7 years ago

@ludwiktrammer - A couple points; I guess I should have been more specific, I was trying to be general.

Anything that starts with NativeScript-dev is a compile/build time plugin and virtually NOTHING changed for compile/build related plugins, so ALL those should stay compatible between 2.5/3.0. 😀

NativeScript-fresco is a Telerik/Progress plugin, any Telerik plugins I would expect to be 3.0 because they have money and people to throw at the issue, and get them done. 😀 The 3.0 update docs were only released a little while ago (20ish days ago); and they (Telerik) already had RC versions of several of their plugins by the time they released the upgrade docs to the community. So the community is going to be way behind compared to Telerik. The info is new and unfortunately runtime plugins changed a LOT, and will require quite a bit of work to convert, the changes are massively breaking changes, no compatibility possible between 2.5 and 3.0.

So my statement should be I don't know of any third party RUNTIME plugins that are fully 3.0 compatible yet, as it requires a lot of work and 3.0 is breaking changes. A RUNTIME plugin for 3.0 will not work in 2.5 (and vise-versa).

At this moment, I show 18 out of the 421 plugins I am tracking (I run the nativescript.rocks sites) have been tagged as 3.0 compatible. The majority of these 18 that I have tracked are by Telerik and -DEV- build time plugins which again require little or no work to convert because the TNS command line tool didn't change any of its API that I know of.

In addition I have chatted with several of the top 10 plugin developers; at this moment most of us have not even yet started on 3.0 compatibility; so the statement I made before was exactly what I meant. (And those that have started on 3.0 have already ran into several issues...)

If you want runtime plugins ; 2.5 is what you want to use for a while. 3.0 will be a while before the community will catch up on porting them.


Now as to this specific plugin, I have over 50 NativeScript plugins; and since I am a contractor; at this moment 3.0 compatibility (for free plugins) is a very very low priority. Putting food on the table is a much higher priority for me. 😀

I am willing to take pull requests, or if any companies want to sponsor 3.0 compatibility! But at this moment any 3.0 compatibility work that I will do will be done first for my paid plugins and paid clients. 😀

ludwiktrammer commented 7 years ago

Sure. By making a ticket I just wanted to make a note of something that should eventually be done in the project. This doesn't mean I'm demanding this from you. Just making a note. I'm note sure my humble ticket deserved such a lengthy and detailed response ;)

I will gladly make a pull request for this. I just have a question on backwards compatibility. Which is the oldest version of NativeScript that have to be supported? I'm asking because I suspect that the main issue is the use of cssClass attribute, which if I'm reading this correctly was deprecated in NS 1.4 and renamed to className (and deleted completely in NS 3.0). So I could make a simple change, and just rename all uses of cssClass in the plugin to className. This would be the simplest change that would keep the code clean, but would be incompatible with NativeScript 1.3 and earlier. Alternatively I could detect if className exists and if not fall back to cssClass.

NathanaelA commented 7 years ago

Due to the number of breaking changes; I wouldn't worry about having it run on anything but 3.0. If people are wanting to use 2.5 (or before) they can install last version of the 2.5 based version of the plugin. When I upgrade any of the plugins to be 3.0; I'll put info in the readme about the last version for 2.5 and I already started adding code to the PNR (http://plugins.nativescript.rocks) to track both v2 and v3 plugins versions separately. ;-)

NathanaelA commented 7 years ago

Thank you for your pull request that fixes this, pull #9 has been accepted and published as v2.00.

ludwiktrammer commented 7 years ago

Thank you!