Nativescript: [TNS 3.0 RC] propertyChangeEvent not firing on views nor observables

[NordlingDev]

Platform: iOS
TNS: 3.0 RC

TextView won't fire a propertyChange event:

UPDATE: At first I thought this had to do with TextView specifically, but it doesn't even work for an observable.

<Page xmlns="http://schemas.nativescript.org/tns.xsd" navigatingTo="onNavigatingTo">
  <TextField id="inputField" />
</Page>

const Observable = require("data/observable").fromObject;

exports.onNavigatingTo = function(args) {
  const page = args.object;
  const inputField = page.getViewById("inputField");
  const inputBindings = Observable({ text: "" });

  inputField.bind({ targetProperty: "text", sourceProperty: "text" }, inputBindings);
  inputBindings.on("propertyChange", e => {
    console.log(e.propertyName); // Never fired
  });
};

Is there something that's changed with event listeners in the 3.0 RC release?

[tsonevn]

Hi @NordlingArt,
While using @rc modules, you should specify the property name.
For example, if you would like to handle the text change event, you should listen for textChange event.
Example:

inputField.on("textChange", (e:PropertyChangeData) => {
    console.log(e.propertyName); 
  });

[NordlingDev]

@tsonevn - Got it. That worked. So how would I observe a property change of any property and not just text? Say if I change inputField.height to something else. propertyChange is no longer in use from what I can understand.

[toddanglin]

Here's another problem I've hit upgrading my app from 2.5 to 3.0. :)

Is this an intentional breaking change? Or should the propertyChange syntax that worked in 2.5.x still work in 3.0?

This workaround does work for me, BUT only when configuring the binding via JavaScript. It does NOT seem to work when trying to configure the binding via XML. Feels like another regression we should prioritize.

[tsonevn]

Hi @toddanglin.
Could you provide sample project or some code snippet, where the problem could be reproduced?

[toddanglin]

Will work on a small project tonight. I should add that my usage is occurring within a modal page on iOS, and I know modals currently have some other issues within iOS. Might be related to the XML binding not working here.

[Nikoms]

I have the same problem on Android.
Same problem in the xml like this. "somethingChanged" is never called:

<TextField propertyChange="somethingChanged"/>

[toddanglin]

@tsonevn In my experience, recreating this problem is pretty straight forward.

1. Add aTextField to a view (or any UI widget with propertyChange)
2. Attempt to bind to the propertyChange or textChange event
3. Observe that neither event is fired UNLESS programmatically binding TextField to textChange event

Here is a repo with a basic project that illustrates the problem:
https://github.com/toddanglin/propertyChange-3971

Doesn't seem to be related to modal pages, either, as problem exists in basic single page example. Also, I expanded the test and it seems to impact any UI widget that used the propertyChange event before 3.0. I've included a test with the Slider to prove it's not just TextField.

Let me know if you are unable to reproduce.

[toddanglin]

Also, was the propertyChange event formally deprecated/removed in 3.0? I don't recall seeing that in the documentation, but it seems UI widgets now have separate events (like textChange or checkedChange).

[hshristov]

@toddanglin Yes, propertyChange was deprecated but we somehow miss to add it to breacking changes document. We will add it because this is a significant change.

[tsonevn]

Hi @toddanglin,
Thank you for the sample project.
Registering for the TextField textChange via XML is not supported in pure NativeScript project.

The Possible way is to get the component by its id from code behind and with the help of on method to handle text change. For example:
XML

<Label text="Text change event" class="h2 text-center" style="margin-bottom: 30;margin-top:30;" />
        <TextField id="myTxt" style="border-bottom-width:1;border-bottom-color:black;font-size:24;" hint="Enter text" />

TypeScript

import {TextField} from 'tns-core-modules/ui/text-field';
import { EventData, PropertyChangeData, Observable } from 'data/observable';
import { Page } from 'ui/page';

export function navigatingTo(args: EventData) {
    let page = <Page>args.object;

    let txt = <TextField>page.getViewById("myTxt");
    console.log("text view");
    console.log(txt);
    txt.on("textChange",(e:PropertyChangeData) => {
        console.log(e.propertyName); 
    });
}

I am attaching a project, where this scenario is shown.
Archive.zip

[hshristov]

Added note in breaking changes document:
https://github.com/NativeScript/NativeScript/blob/master/Modules30Changes.md#events-raised-when-property-value-change

[toddanglin]

@tsonevn Yep. I demonstrated that approach in my sample project, too. :)

@hshristov Is it intentional that you can no longer declaratively bind these events via XML? Or is that a bug? Seems odd to me that this is unsupported given the ability to declaratively bind most other events via XML.

Removing the propertyChange event, while a bit of a painful breaking change, makes sense if it was necessary for the desired performance gain. THAT SAID, all of the documentation and TypeScript intellisense still refer to propertyChange, so we should prioritize fixing that up so people are not steered towards this now obsolete event.

[toddanglin]

Hopefully we can re-enabled declarative XML support for these propertyChange events. As I try to convert my app, it seems like it will be difficult to handle propertyChange events programmatically from elements within containers like Repeaters (think: a Repeater with a declarative template that renders a Switch). And it just feels odd to require programmatic event wiring for this event when you can do everything else with simple declarative binding syntax.

Here is my current workaround (simplified for clarity)...

myView.xml

<Repeater items="{{ items }}">
        <Repeater.itemsLayout>
            <StackLayout />
        </Repeater.itemsLayout>
        <Repeater.itemTemplate>
              <Switch checked="{{ (item.level === 0) ? false : true }}"
                    isEnabled="{{ isLoading ? false : true }}" loaded="bindChangeLevel" />
     </Repeater.itemTemplate>
</Repeater>

myView.ts

export function bindChangeLevel = (args: EventData) => {
      let ele = args.object;
      ele.on("checkedChange", myViewModel.onCheckedChange);
}

[toddanglin]

Just to connect the dots, this issue was also being discussed at length on the NativeScript forum:
https://discourse.nativescript.org/t/textfield-onchange-propertychange-change-event/1314

Lots of people struggling with the absence of XML binding for these property events in non-Angular projects.

[swlemp]

@tsonevn @hshristov Please update https://docs.nativescript.org/core-concepts/events#propertychange-event

Looks like the new syntax doesn't support changes inside repeaters, will have to restructure code around this by creating the child views in javascript.

[LorenDorez]

I have run into this. I have a view with several textfields and seems like a major issue that i cant set textChange event via XML. What is the reasoning behind why it cant be done or added?

[NickIliev]

With NativeScript v3.x.x we do not have access to valueChange event via the XML files. Done for compatibility with Angular where this is the standard syntax

[bearoutthere]

i gotta say this is the most drastic and unpleasant surprise i've encountered while working with Nativescript. So in order to accommodate an optional framework the core functionality is being intentionally crippled. I got a form with multiple tabs, each with multiple text fields. In order to add error checking on those fields while the user types Nativescript is forcing me to add dozens lines of code just to get the basic bindings to work on each text field. Rather surprising that nobody on the Nativiscript team stood up at that meeting to say that this is a very bad solution and that the core Nativescript developers should not be penalized for something that Angular is doing. Declartive UI with XML is one of the major benefits of NS, that includes basic event bindings.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.