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

Very cool! Curious to learn more about how it works #5

Closed
loudmouth opened this issue May 4, 2021 · 4 comments
Closed

Very cool! Curious to learn more about how it works #5

loudmouth opened this issue May 4, 2021 · 4 comments

Comments

@loudmouth
Copy link

loudmouth commented May 4, 2021

Just want to say I think this is an extremely cool project! It's cool to see how much energy you are putting into it.

I am curious to learn more about how the build system works, including what inputs are expected and how they might be structured. What dependencies (for instance, running the demo app, i had to install maven and wget on Mac), and what outputs, and intermediate outputs are generated.?

As far as I can tell, the build tool uses webpack to generate some modules, and then those modules are injected into the ftl templates? How is the window.kcContext context populated?

Anyway, maybe i'm just that kind of person who needs to know how things work before moving forward, but it would also help with integrating with other build tools such as Bazel, and maybe would help in getting a little more traction :-)

@garronej
Copy link
Collaborator

garronej commented May 4, 2021

Hi @loudmouth,
I am at work, I'll answer when I get back home. :)

@garronej
Copy link
Collaborator

garronej commented May 4, 2021

Thanks for the kind words. 😃
The build tool doesn't use Webpack per say,
the input of the tool is the build/ directory that is generated after you run yarn build in a create-react-app project.
What this tool actually does to make it work is:

  1. It converts the index.html into login.ftl, register.ftl... basically just making copies of the index.html and changing the extension to .ftl.
  2. It injects FreeMarker code to convert the data_model into JavaScript object. See here for login.ftl. I have a file like this for every Keycloak pages. (1)
  3. Here, i'll admit it get a bit sketchy. I parse the minified JS code with regexp to look for x.y+"static/ and fix it so it can work when Keycloak is serving the app. This may break with future versions of WebPack but I think I will be able to quickly release a patch if it ever does.
    I also remplace the imports in CSS files using CSS variable, this is less likely to break in the future.

Once we get the window.kcContext populated and the app running in Keycloak then it's easy to translate the default pages into react component.

Of course this is a very simplified summary of what is actually happening.
If you want to learn more, you can explore the build_keycloak/ dir that you get when you run yarn keycloak on the demo project.
Ultimately the output of the build tool is a build_keycloak/target/*keycloak-theme*.jar that can be loaded in Keycloak

Regarding the requirements I wrote a small section about it in the README

If you provide me with the build directory (the directory ready to be served as a static site) generated by some other bundler, I could tell you how easy/hard it will be to adapt Keycloakify to work with it. 👍🏻

(1) I am not particularly proud of the way I implemented that.
I should not have a specific .ftl to js script for every page but rather use something like:

<#list .data_model?keys as var>
    ${var}
</#list>

I will re-write it later.

@loudmouth
Copy link
Author

awesome. thanks for this writeup. I only have one question at this point:

It injects FreeMarker code to convert the data_model into JavaScript object

I had actually seen that javascript inside the rendered templates, and it makes sense. What I'm curious about it, how did you figure out what data_model was? Is it somewhere in the Keycloak docs?

@garronej
Copy link
Collaborator

garronej commented May 7, 2021

No, I inferred from the usage in the .ftl files of the base theme.
That's alsow how I wrote the types definitions.
And by the way, I put so many try catch just so that if something changes in the future version of Keycloak the theme does not break immediately. This way we have a "best effort" approach.
The problem of inferring from usage though is that I am quite sure I am missing interesting values out that are defined but not used in the default themes. Custom Keycloak plugins (such as this one with authorizedMailDomains fore example) can populate values in the .data_model. That's why it is really the next todo to write a ftl script that populate a JS object from it's .data_model.

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

No branches or pull requests

2 participants