Weekly update:
Function complete:
The new codebase now is function complete, I just added an alpha-1 tag.
Work is still done regarding improving the code a little bit
improving the jsdoc comments and also Udo wants to get something
regarding shadow dom updates in.
But we are now on the same function level except for the dropped stuff
as the old implementation.
So what does that mean? The code is not fully ready to be merged into
the myfaces codebase but you can start to test it by dropping it in
yourself.
In https://github.com/werpu/jsfs_js_ts/tree/master/dist/window
you can find builts for the development and production environments.
Please drop it in and give it a testrun, any feedback, negative,
positive, bugs, is appreciated.
Cheers
Werner
Am 22.11.19 um 17:45 schrieb Werner Punz:
The usual weekly update...
Changes can be seen as usual on the github project:
https://github.com/werpu/jsfs_js_ts
Following
all my integration tests now pass
IE11 support now is in
I now also have relative concrete code and performance numbers
dev build: unmangled roughly 250 kbypte,
prod: compressed es5 level 89Kbyte,
if you pull the es level up to es2015, 69kbyte.
Higher ES Levels than 2015 don´t have a huge impact anymore.
Speed, roughly 25% slower than the old code, which was highly optimized
and low level
on an extreme case with a form with a few hundred inputs (my spreadsheet
test) on chrome.
IE11 might have a higher hit, not tested yet.
The reason is a higher abstraction I have. Instead of operating directly
on nodes and setting the attributes straight on dom
I now operate on JQuery like monads and selectors which then route into
the dom.
Instead of looping over elements, I stream, flatmap map and reduce them.
Instead of pulling the map and having asynchronous callbacks I work now
with
promises and shim them if not provided.
All this improves readability but sacrifices some performance.
Given that normally the performance of the ajax part is not really where
the problem is,
I can live with that for the time being, should the users complain
(which I frankly doubt given that jquery and other frameworks
usually provide bigger slowdowns), then I could have another round of
optimizations.
I guess 5-10% still is possible without sacrificing readability too much.
The plus side is, the code is very readable now and we can ramp
up Ecmascript versions on the fly without a single code change.
Happy weekend
Werner
Am Fr., 15. Nov. 2019 um 16:24 Uhr schrieb Werner Punz
<[email protected] <mailto:[email protected]>>:
Another small update...
112 Tests atm (including the base framework)
and the first 9 of my around 18 integration tests now pass properly,
have not looked to deeply into the others so I am not sure how many
really still fail atm.
The build now also works on windows, the reason for that was, that I
have to send in my Mac for repairs soon (keyboard), so I had to move
the
build over to the desktop computer and for testing ie11 doing it on
Windows 10 makes perfect sense.
Also the viewstate handling now got a major cleanup and is very readable
https://gist.github.com/werpu/f46ccb54ce89acc0df933050df35f3cf
I still postpone the eval and viewstate to the post update processing
phase on the client
this has never caused any troubles with the old implementation so I
keep
it, it just now is cleaner.
In the example the viewstate is stored and then after all udpates are
performed the viewstate is applied by the second method.
So what is still pending...
a) First all my 18 integration tests must pass and I have to convert
parts of them to permanently integrated unit tests where it makes sense.
(just ported the test for the viewstate handling over into a unit test)
b) I have to get the code then running on the only supported legacy
browser (IE11)
it should theoretically work with a bunch of fixes, practically I
probably have to change the
packaging format and other smaller tweaks.
