Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uplift to use cht-form web component #245

Merged
merged 40 commits into from
Apr 1, 2024
Merged

Uplift to use cht-form web component #245

merged 40 commits into from
Apr 1, 2024

Conversation

jkuester
Copy link
Contributor

@jkuester jkuester commented Oct 26, 2023

So, let me start with a profuse apology for the size of this PR. There just was not really any way to do this incrementally since this is basically shifting some fundamental things with regard to how the cht-core resources are consumed within the Test Harness.

I am very aware that I have made a ton of design decisions (big and small) all on my own here that may or may not be acceptable to the project maintainers. 😓 I consider this PR to be more of a "production ready" proof-of-concept to show how the integration could be done. I am exploring a lot of new ground here, and have something that seems to work pretty well, but I welcome any and all ideas on better ways to approach this!

Overview

The goal of this PR is to support depending on the latest version of code from cht-core by leveraging the new cht-form functionality for rendering forms. (Previously we were blocked from depending directly on logic in cht-core/webapp since it is TS code written for Angular. The cht-form web component allows us to extract this logic into html/js/css resources that the harness can depend on directly.) As a part of adjusting the dependency approach, I have sought to bring back the ability to target multiple different versions of cht-core code from the same version of the Test Harness (though this will only be available for future versions of the CHT).

Build tree

I have created this diagram to try and make it easier to understand how the various pieces and files fit together. Everything in this diagram outside the build directory gets committed to the repo. The dist/form-host.dev.js and the dist/all-chts-bundle.dev.js files are rebuilt every time the build.sh script is run, but the various artifacts inside the dist/cht-core-x-x directories are only (re)built as needed.

flowchart TD
    subgraph cht-bundles
        cht-bundles/all-chts-bundle.js[all-chts-bundle.js]
        subgraph cht-bundles/cht-core-4-6
            cht-bundles/cht-core-4-6/bundle.js[bundle.js]
            cht-bundles/cht-core-4-6/xsl-paths.js[xsl-paths.js]
        end
    end
    subgraph build
        subgraph build/cht-core-4-6[cht-core-4-6]
            build/cht-core-4-6/cht-form[build/cht-form]
            build/cht-core-4-6/ddocs[ddocs]
            build/cht-core-4-6/api/src/xsl[api/src/xsl]
        end
        build/cht-core-4-6-ddocs.json[cht-core-4-6-ddocs.json]
    end
    subgraph dist
        dist/all-chts-bundle.dev.js[all-chts-bundle.dev.js]
        dist/form-host.dev.js[form-host.dev.js]

        subgraph dist/cht-core-4-6
            dist/cht-core-4-6/cht-core-bundle.dev.js[cht-core-bundle.dev.js]
            dist/cht-core-4-6/cht-form.js[cht-form.js]
            dist/cht-core-4-6/xsl[xsl]
        end

    end
    subgraph src
        src/harness.js[harness.js]
        subgraph src/form-host[form-host]
            src/form-host/index.js[index.js]
            src/form-host/form-host.html[form-host.html]
        end
    end


    build/cht-core-4-6 --> cht-bundles/cht-core-4-6/bundle.js
    build/cht-core-4-6/api/src/xsl --> dist/cht-core-4-6/xsl
    build/cht-core-4-6/ddocs -->|compile-ddocs.js| build/cht-core-4-6-ddocs.json

    cht-bundles/all-chts-bundle.js -->|webpack.config.js| dist/all-chts-bundle.dev.js
    dist/cht-core-4-6/cht-core-bundle.dev.js --> cht-bundles/all-chts-bundle.js
    dist/cht-core-4-6/xsl --> cht-bundles/cht-core-4-6/xsl-paths.js

    build/cht-core-4-6-ddocs.json --> cht-bundles/cht-core-4-6/bundle.js
    cht-bundles/cht-core-4-6/bundle.js -->|cht-bundles/webpack.config.cht-core.js| dist/cht-core-4-6/cht-core-bundle.dev.js
    cht-bundles/cht-core-4-6/xsl-paths.js -->|cht-bundles/webpack.config.cht-core.js| dist/cht-core-4-6/cht-core-bundle.dev.js

    
    build/cht-core-4-6/cht-form -->|cht-bundles/webpack.config.cht-core.js| dist/cht-core-4-6/cht-form.js

    src/form-host/index.js -->|webpack.config.js| dist/form-host.dev.js
    dist/form-host.dev.js --> src/form-host/form-host.html
    dist/cht-core-4-6/cht-form.js --> src/form-host/form-host.html

    dist/all-chts-bundle.dev.js --> src/harness.js
    src/form-host ----> src/harness.js
Loading

Details

  • Recent changes to the cht-core repository make it difficult (impossible?) to have it listed as a dependency in the package.json (get errors when doing npm install). This is one of the reasons I switched to manually cloning the repo.
  • The main motivation for introducing the new cht-core-bundle.dev.js files was to avoid having to rebuild all CHT versions (contained in the all-chts-bundle.dev.js) just to add/update one of them. I have mild hopes that this might allow for longer-term support in the harness for particular CHT versions.
  • For what its worth, I do not believe that any of the font/icon files in the dist/cht-core-x-x directories are strictly necessary for the Test Harness to function (though removing them may affect how forms are displayed in the Project Explorer). Those are getting pulled over automatically by Webpack due to their usage in the css, but they should be pretty easy to exclude if we wanted to...
  • The most significant changes I had to make to the test harness logic were in the form-filler.js file where I changed the logic to be less tightly coupled to internal Enekto code and more able to just directly consume the content on the page.
  • For the Project Explorer, I have tried to take the most simple approach to integrating with cht-form.
    • I think a lot more could be done in terms of making it look/work even better, but at least I don't think I have made it any worse!
    • The main difference in behavior is that now there is some responsiveness based on the width of the browser window. If you make the window too narrow, it will switch into the "mobile" view for the form and hide the side-bar. This could be considered a feature, but as of yet there is no way to get back to the list of forms from this view.... 😅

I am pretty sure this closes #138 and closes #204 (I guess this is as close as we get to 4.1). It might also make sense to say this addresses #46 as well since basically all the Enekto widgets should be functional at this point except for the db-object-widget (which is tracked separately in #184)...

build.sh Outdated Show resolved Hide resolved
build.sh Outdated Show resolved Hide resolved
build.sh Show resolved Hide resolved
@jkuester jkuester marked this pull request as ready for review January 10, 2024 23:02
@jkuester
Copy link
Contributor Author

@kennsippell please add/redirect reviewers for this PR as makes sense!

This is not particularly urgent as it depends on the as of yet unreleased cht-core 4.6.0, but it will be required for running config tests against the new Enekto version coming in 4.6.0, so we don't want to wait too long here!

Copy link
Member

@kennsippell kennsippell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love this change

CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
package.json Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
build.sh Outdated Show resolved Hide resolved
test/app-forms.spec.js Show resolved Hide resolved
package.json Show resolved Hide resolved
src/core-adapter.js Show resolved Hide resolved
src/form-host/form-wireup.js Show resolved Hide resolved
test/app-forms.spec.js Show resolved Hide resolved
Copy link
Member

@kennsippell kennsippell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry this review took so long... this is looking great!

package.json Show resolved Hide resolved
src/form-host/index.js Show resolved Hide resolved
package.json Show resolved Hide resolved
src/form-host/cht-environment.js Outdated Show resolved Hide resolved
# Conflicts:
#	dist/all-chts-bundle.dev.js
#	dist/all-chts-bundle.dev.js.map
#	dist/form-host-cht-core-4-0.dev.js
#	docs/Harness.html
#	docs/core-adapter.js.html
#	docs/dev-mode_mock.cht-conf.contact-summary-lib.js.html
#	docs/dev-mode_mock.cht-conf.nools-lib.js.html
#	docs/dev-mode_mock.rules-engine.rules-emitter.js.html
#	docs/form-host_form-filler.js.html
#	docs/global.html
#	docs/harness.js.html
#	docs/index.html
#	docs/jsdocs.js.html
#	docs/mock.cht-conf.module_contact-summary-lib.html
#	docs/mock.cht-conf.module_nools-lib.html
#	docs/mock.rules-engine.module_rules-emitter.html
#	docs/module-core-adapter.html
@jkuester
Copy link
Contributor Author

@kennsippell this should be ready to merge/release at your convenience!

It looks like the release-notes have not been updated in awhile. I could not find an automated way to generate anything, so I made an attempt to manually pull something together based on the git commit history and the changes to the version in the package.json. I doubt it is perfect, but probably better than nothing.

@kennsippell kennsippell merged commit 9b3043f into master Apr 1, 2024
2 checks passed
@kennsippell kennsippell deleted the 7462_forms_module branch April 1, 2024 08:53
@medic-ci
Copy link

medic-ci commented Apr 9, 2024

🎉 This PR is included in version 1.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for Core 4.1 Include support for CHT-Core latest releases
3 participants