You should notice speed improvements on pages that have many data binding expressions and data changes frequently but only few expressions need to be rerendered not everything.
I have lots of those kind of pages. My dashboards are all data bindings and lots of them. Not noticing anything significant. Maybe because I am using local MAMP server and remote database?
This intrigues me. Makes me think that the first loading of the page would be normal speed but reloads and revisits should load faster as it only has to fetch new data? Am I thinking correctly on that?
Not really is about changing just a few expressions or values later on.
In previous App Connect version we had to traverse and evaluate all expressions on the page to see if they produce new results and then apply those.
Now in the new version we traverse much wisely only checking expressions that really reference to the data being changed.
So App Connect is getting more smarter
Lots is very subjective Maybe you don't have as many as you need to notice the difference.
I have the impression that @Antony might have a good working example to throw at this
Btw we will be also dropping the IE support officially!
As there is no browser to find any longer to test on and we also want to lose some dead weights.
Edge 12 will be the absolute minimum needed for App Connect.
@patrick Perhaps this is just some temporary debugging?
Yes indeed this was some test logging, will be removed in the final version.
We greatly optimized parsing and evaluating expressions enclosed {{ and }} in larger text blocks.
Now just the expression is replaced with its value. Before we replaced the whole text block.
still same problem persists.
This seems like a server side problem - not really an App Connect issue.
this is an already working app all i did was replace appConnect.js with new one.
This is how I entered a value for the limit parameter. When this value is updated everything works.
With the latest version everything is looking good to me. I don’t notice speed improvements but that is something I expect as I have fairly high spec devices and I don’t abuse bindings because I know they have a cost. I’m pretty sure low-end spec device users will appreciate this improvement guys
Thanks for this.
Will try this out.
@patrick does this change anything regarding this comment from you a while ago?
Feedback:
After updating with the new appconnect file and reload my most intensive page (in terms of expressions, formatters and appconnect elements)… something goes horribly wrong.
My browser tab wasn’t responding, I think it took 3-4 minutes, then it finally loaded.
In the console I’m seeing new messages:
This didn’t print before.
Also I’m getting Maximum Stack Size exceeded errors:
They’re still happening as I write this reply.
Would love to help, what info do you need to debug this?
New update, get the update by downloading the file from the topic again.
- Reverted code for parsing the text nodes, code could cause loops in some cases
- For several components it is still needed to call the update method of that specific component, so we call update for every component until we have finished updating the components.
- Updated core component update method
- Several code updated to newer javascript now that IE is dropped
same issue persist
Check what data you are sending to SC from that page. Maybe you are sending data through a binding that is being parsed incorrectly by the new version.
hello @JonL , there is no problem with data parsing. The problem is as follows;
I am listing the data from server connect in a table. In this list, I determine the number of rows that will appear on the page with the help of a select box. ( ie 10 lines or 25 lines per page ) . I think the problem is the select box value is not read after server connect is installed. But this old version works fine with appConnect.js.
Well that’s what I was more or less saying. That’s data that has to be sent to SC somehow and it’s not being sent correctly, right?
Given that your error is showing in the SC action and your are getting problems with the new AC it’s something that is not being sent correctly to the server. In this case I’m assuming it’s the limit parameter that shows empty and it’s coming from the select as you mention.
Probably now it’s easy to reproduce for @patrick