npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

jsf.js_next_gen

v4.0.4-beta.4

Published

A next generation typescript reimplementation of jsf.js

Downloads

659

Readme

🚀 Scratchpad for the typescript based reimplementation of jsf js

What is this?

This project is a work in progress for a next gen typescript based reimplementation of jsf.js/faces.js

The main goal is maintainability. It omits legacy browsers with Edge 14 and Ecmascript 2015 being the browser and ES baseline for the moment.

It uses functional constructs on micro scale to keep the maintainability and uses my own mona-dish project as core framework base, to avoid unnecessary colliding dependencies.

But it still uses classes modules and inheritance for code structuring. The reason for this is, I do not like the one function for all approach, especially given we have Typescript now as implementation language which allows a proper code structuring and modularization.

Webpack can take care of the packaging.

Having smaller code parts, makes it easier to test certain aspects of the implementation.

Also one additional aspect of the new implementation: it has a proper test coverage via Mocha based unit tests.

This was also severely lacking in my old implementation where I just ran a set of 20 integration tests on macro scale.

Status

We now have a stable version! The current stable version (and first stable version is 4.0) Why 4.0 and not 1.0? The reason for this is, it is faces 4.0 compliant (but also faces 2.3 compliant) and also used in MyFaces 4.0. In order to avoid version confusion the projects stable version always will be in sync with the Faces implementation level it provides now and in the future.

Special info

Due to a small api change, if you want to embed the 4.0 version (faces.js) in your code, a new attribute specified by the Faces 4.0 spec is not set at its proper value, contextpath. This attribute atm is a value expression which needs to be set by the loading implementation.

Now if you want to provide your own embedded solution and you will have to set this value yourself. While my code does not use the attribute in the faces namespace, other libraries or the users might.

If you serve the code from MyFaces 4 instead of embedding it, the value will be preset by the internal resource loader.

The JSF 2.3 version (jsf.js) is not affected by this change, so nothing needs to be done. In fact the contextpath attribute is not present there. All other attributes behave the same in both versions as in the original legacy codebase.

General build

run

  • npm install

On Windows

if not done yet

  • npm install --global --production windows-build-tools

run

  • npm install

Tests

run

  • npm test

Test Coverage

  • npm coverage

Changelist compared to the original implementation

  • no_portlet_env is no more the configuration parameter 'no_portlet_env' has become obsolete with jsf 2.3 which introduced a proper namespaced viewstate handling so it is gone now

  • pps disabled for the moment

We had a special pps handling introduced in myfaces, a feature probably never used (you basically could reduce the parameters sent down by sending a list of pps ids). I have disabled it for the time being. The code still is in there for the moment, but will be dropped if no demand arises to enable it again.

  • legacy browsers

In order to improve the maintainability I have dropped a lot of shim and legacy code which was needed to support old browsers. Since our main aim is long term maintainability there is a clear cut. The lowest supported browser for the moment is Edge 14. Older browsers are now cut off. This should suffice for most, if not all important environments. If you still use an older browser than Edge 14 you still can revert to the old codebase for the time being (final cutoff point probably will come within the next few years)

  • performance

Given that we now have faster browsers and end user devices in the mobile area than 10 years ago and the spec conformity has improved a lot, my main focus was maintainability. Maintainability and readability now comes before performance. So I sacrificed some of the performance to achieve it. Given that the most critical performance hits do not happen in the ajax area this is a sacrifice I can live with, for the time being.

  • Client side i18n

The client side i18n error message translations have become more of a liability than a feature. For the time being all client side errors are reported in english. I can reintroduce them, if there is real demand. But the size and maintainability tradeoff, compared to what they bring was not worth it to keep them anymore.

  • Mapping file support

The original implementation had various builds to support easier debugging (split, combined, compressed)

We now have only two builds prod and development. However I have introduced a mapping file support. To enable this support you have to reference the FacesJSMappingDecorator unless the mapping file is reachable via the normal request (mapping files are bundled). This works for normal includes, but if you include the jsf.js in a resource library you have to use the decorator provided.

Usage faces-config.xml


<application>
    <resource-handler>com.example.jsfs_js_ts.FacesJSMapFileResourceWrapper</resource-handler>
</application>

This resource decorator detects automatically a faces*.js file coming from a resource library and adjusts the references in the resource accordingly to the request patterns

Upload Support

As non standard extension XMLHttpRequestUpload support is added

faces.ajax.request(document.getElementById("cmd_eval"), null,
{
    render: '@form',
    execute: '@form',
    myfaces: {
        upload: {
            progress: (upload: XMLHttpRequestUpload, event: ProgressEvent) => {
                caughtProgressEvents.push(event);
            },
            preinit: (upload: XMLHttpRequestUpload) => preinitTriggered = true,
            loadstart: (upload: XMLHttpRequestUpload, event: ProgressEvent) => loadstartTriggered = true,
            load: (upload: XMLHttpRequestUpload,  event: ProgressEvent) => loadTriggered = true,
            loadend: (upload: XMLHttpRequestUpload,  event: ProgressEvent) => loadendTriggered = true,
            error: (upload: XMLHttpRequestUpload,  event: ProgressEvent) => errorTriggered = true,
            abort: (upload: XMLHttpRequestUpload,  event: ProgressEvent) => abortTriggered = true,
            timeout: (upload: XMLHttpRequestUpload,  event: ProgressEvent) => timeoutTriggered = true,
        }
    }
});

Changes since 4.0

  • Elimination of Streams in favor of native arrays
  • Providing an internal non intrusive shim for browsers which do not have array map and flapMap (older Edge and Chromium versions) - done in mona-dish
  • Adding a progress monitoring functionality under the myfaces namespace
  • Bugfixes which improve tck compliance
  • Integration in myfaces 4.0+ as default faces.js implementation