Configuration API #504

zachasme · 2025-12-18T10:39:30Z

Based off suggestions from @jorgemanrubia, this PR allows configuring lexxy instances in three layers:

Default config properties for all Lexxy instances.
"Preset" configurations so that you can re-use special instances here and there.
Instance-level configuration via element attributes for one-off overrides.

// In app JS initializer
import { configure } from "lexxy"
configure({
  default: { ... }, // To override Lexxy defaults
  simple: {
    toolbar: false
  }
})

// Reference the preset and override specific values
<lexxy-editor preset="simple" attachments="false" ...>

I took into consideration the work on custom-upload-events, which will require:

"global" options not attached to any instance, due to the static nature of Lexical's importDOM API.

lexxyConfig.global.get("attachmentTagName")

Note that I'm only exposing the configure function as public API, but we could include a getter if end-users need to read current config values.

As for next steps:

We can introduce more fine-grained control over e.g. the toolbar. This will require additional logic around merging things like {toolbar: true} and {toolbar:{bold:false}}.
Lexical Extensions! Should we consider refactoring parts of Lexxy into a set of extensions?

samuelpecher

Nice. I like that configuration can still be done on the element directly. Just a couple comments on attachment tag name and a potential listener issue.

Overall I think we should build a way to provide the config from Rails as well.

Lexical Extensions! Should we consider refactoring parts of Lexxy into a set of extensions?

This feels like the right direction! I was going to try it with the next feature to make sure we can still keep the nice OO-patterns established in Lexxy.

samuelpecher · 2025-12-18T10:50:11Z

src/nodes/custom_action_text_attachment_node.js


  createDOM() {
-    const figure = createElement("action-text-attachment", { "content-type": this.contentType, "data-lexxy-decorator": true })
+    const figure = createElement(lexxyConfig.get("global.attachmentTagName"), { "content-type": this.contentType, "data-lexxy-decorator": true })


What do you think about passing the tag name to the Node constructor and keeping as internal node state rather than hooking into the config at every step?

Same would apply to ActionTextAttachmentNode

I like it! I noticed you did the same for custom-upload-events, and considered including it here. But I also wanted to keep this minimal.

If you are expecting to merge custom-upload-events soonish I'd rather not introduce it here, otherwise I'm ok to include it.

I'm splitting that branch into separate PRs back to main, so I'll handle that then 👌

This would be a quite edge case but if we kept it in the internal node state, it would be copied/pasted carrying the tag, which assumes that the editor where you are pasting the node has the same override. I would keep it simple with a global access I think.

@jorgemanrubia: the exchange format will be text/html unless the editors share the same namespace. The rendered HTML will include the rendered tag name and I think we should match that behavior.

Though I do propose that differently configured Lexxy editors shouldn't share a namespace and we should set it depending on the loaded config:

// ... namespace: `Lexxy.${configName}`,

src/config/configuration.js

jorgemanrubia

Good spike @zachasme!

We need to add tests here. So far, Capybara has served us well. But here, to test the configuration interfaces and such, I think we could add jest to Lexxy. I would still rely on Capybara as our main testing mechanism, but it is nice to have more traditional unit testing available too. We could configure in the local CI script and in GH actions too. That would let us test the Configuration objects properly here.

I would still add some high level system tests to make sure the configurations work as expected. I would be fine with just testing the overrides in capybara, assuming the system is tested through jest. WDYT?

jorgemanrubia · 2025-12-18T12:02:26Z

src/config/dom_purify.js

-  ALLOWED_TAGS: ALLOWED_HTML_TAGS,
-  ALLOWED_ATTR: ALLOWED_HTML_ATTRIBUTES,
-  SAFE_FOR_XML: false // So that it does not strip attributes that contains serialized HTML (like content)
+lexxyConfig.listen("global.attachmentTagName", (attachmentTagName) => {


Why are we observing changes here instead of just grabbing the configuration directly? Is this a matter of changing the initialization order or something like that?

This is necessary if we want modify the attachmentTagName using Lexxy.configure. Otherwise DOMPurify will remain configured with the default value.

Alternatively, DOMPurify.sanitize accepts a second configuration argument. We could avoid listening for changes if we build a fresh configuration for each call.

I was thinking of mirroring Trix's implementation: call setConfig before each call. This allows a known good configuration and keeps the sanitize call clear.

Then we can 'pull' config and not need the listeners

Sorry I still don't understand.

We configure dompurify when running:

import "./config/dom_purify"

Wouldn't this be a matter of requiring the global configuration before that code runs, and then making dom purify use the global configuration?

jorgemanrubia · 2025-12-18T12:03:14Z

src/elements/editor.js


  get #hasToolbar() {
-    return this.getAttribute("toolbar") !== "false"
+    return Boolean(this.config.get("toolbar"))


Is this keeping the default true value?

Yes. The Boolean call technically isn't required, but it felt right since you can pass an element ID to toolbar.

I still think it is redundant. Isn't JS semantics enough for evaluating true/false enough here? I would only add additional code here if it is really justified. It confuses me a bit whenever I see it.

jorgemanrubia · 2025-12-18T12:08:50Z

src/config/configuration.js

+    return node
+  }
+
+  merge(config, into = this.#tree) {


I think the into param is a bit confusing. Why would you like to change that to other thing? This is an instance method, it is expected it will act on its private data. I see you use it recursively but it kind of makes the interface less clear. I would consider extracting a deepMerge helper method to helpers/hash_helper.js and reuse here. You could move arePlainObjects as a private (not exported) function there too.

src/config/configuration.js

jorgemanrubia · 2025-12-18T12:12:56Z

src/config/configuration.js

+
+      node = node[key]
+      if (node === true || node === false) {
+        return node


I think this should be more agnostic about the boolean value. It should loop through the path and return whatever it is at the end. Why that return?

The intention was to eventually support different levels of granularity such as

{ toolbar: true } // or { toolbar: { bold: true } }

Such that querying for "toolbar.bold" would return true in both cases.

Hmm not sure about this, it does not look super intuitive. I think it is important that we keep the core config abstraction lean and generic. I would rather interpret this at toolbar-rendering time: assume that everything is on unless there is a FALSE in the settings.

jorgemanrubia · 2025-12-18T12:16:37Z

src/config/configuration.js

+    return into
+  }
+
+  listen(path, listener) {


As mentioned, the listening mechanism seems a bit excessive to me. This is configuration stuff. It should be initialized and used, but why would you like to subscribe to dynamic changes?

jorgemanrubia · 2025-12-18T12:24:44Z

src/editor/configuration.js

+  }
+
+  get(path) {
+    if (this.#preset) {


I would define a getter get config at the editor level, that returns the value of the attribute or "default" if the attribute is not set. Then, this can be deterministic. You just get the value of editorElement.config. You can rename the current config to configuration to remove the collision.

jorgemanrubia · 2025-12-18T12:27:56Z

src/editor/configuration.js

+
+  get(path) {
+    if (this.#preset) {
+      return super.get(path) ?? lexxyConfig.get(`${this.#preset}.${path}`) ?? lexxyConfig.get(`default.${path}`)


Why checking the path before prepending the prefix path segment? I think this should be more deterministic. It should invoke the parent with the path prepending the editorElement.config segment.

I am not sure about the inheritance here. Configuration feels like a simple data structure you use. I think EditorConfiguration could have an attribute configuration that it uses to delegate the get and set, but inheriting from it feels slightly off to me.

Why checking the path before prepending the prefix path segment? I think this should be more deterministic. It should invoke the parent with the path prepending the editorElement.config segment.

I wanted to support three possible levels of configuration: element attributes toolbar=false, editor presets config=simple, and defaults. Unless there is no preset selected in which case we only check element attributes and defaults.

I am not sure about the inheritance here. Configuration feels like a simple data structure you use. I think EditorConfiguration could have an attribute configuration that it uses to delegate the get and set, but inheriting from it feels slightly off to me.

Hm, yes, I'll try that!

jorgemanrubia · 2025-12-18T12:30:46Z

src/editor/configuration.js

+
+  get #overrides() {
+    const overrides = {}
+    for (const attribute of EditorConfiguration.attributes) {


Instead of having to maintain the list of attributes in this place too, I would grab the list from the defaults Object.keys(configuration.get("defaullt")). This also adds some basic protection against typos in configuration keys when overriding them.

Ooh nice! 👌

jorgemanrubia · 2025-12-18T12:32:05Z

src/config/configuration.js

+      }
+    }
+
+    return node


If the configuration key is missing, I wonder if this should throw an error. I think it should, to prevent entering typos when trying to override settings, which could be hard to debug.

Hm, that's a good idea. Currently I'm returning null so I can detect and fallback to preset/default in EditorConfigutaion. But I could validate against the structure in default if we keep all possible configs in there.

jorgemanrubia · 2025-12-18T12:45:33Z

src/editor/configuration.js

+  }
+
+  #parseAttribute(attribute) {
+    const value = this.#editorElement.getAttribute(attribute)


You could use JSON.parse instead of the ad-hoc booelan parsing. That way, it will work for boolean value types supported by JSON. This could be handy when providing Rails attributes during rendering.

zachasme · 2025-12-18T14:04:51Z

Thank you for the feedback @samuelpecher and @jorgemanrubia! 👌

We need to add tests here. So far, Capybara has served us well. But here, to test the configuration interfaces and such, I think we could add jest to Lexxy. I would still rely on Capybara as our main testing mechanism, but it is nice to have more traditional unit testing available too. We could configure in the local CI script and in GH actions too. That would let us test the Configuration objects properly here.

Agreed. I wanted to hear your thoughts on the general approach before writing new tests.

I would still add some high level system tests to make sure the configurations work as expected. I would be fine with just testing the overrides in capybara, assuming the system is tested through jest. WDYT?

Yes, I think adding jest is justified at this point. Though I'd rather tackle that in a separate PR. Until we introduce more granular options for toolbar/etc, I believe I can cover most of the configuration system with some high-level system tests.

jorgemanrubia · 2025-12-18T14:14:57Z

To me, the motivation of jest would be to test the system we are bootstrapping here, more than the granular options themselves. I think those tests belong to this PR.

samuelpecher · 2025-12-18T14:19:59Z

Good spike @zachasme!

We need to add tests here. So far, Capybara has served us well. But here, to test the configuration interfaces and such, I think we could add jest to Lexxy.

If you're open to it I recommend vitest which is powered by the rapid vite which uses esbuild

zachasme · 2025-12-18T14:29:37Z

To me, the motivation of jest would be to test the system we are bootstrapping here, more than the granular options themselves. I think those tests belong to this PR.

Makes sense. Alright, I'll set up jest here. @samuelpecher I'll give vitest a spin, it's "jest-compatbile" so why not? 👍

jorgemanrubia · 2025-12-18T16:52:17Z

app/assets/javascript/lexxy.js

    return this.isEmpty || this.toString().match(/^\s*$/g) !== null
  }

+  get preset() {


Since you configure the element with config= it makes sense to me that this is get config instead of using a new name. We do that with other attributes lke name. Feels more consistent. Any reason to use a different name here?

No reason, they should definitely be consistent. I've been back and forth on config/preset. I prefer preset, it feels more descriptive than the generic config.

But config is what we expose as the public API to be used by the editor users. What is confusing to me is using different terms here:

<lexxy-editor config="whatever"

I would expect that if you do editorElement.config returns whatever. Now, we want to make that, if config is not set, then its default value is default, so that you can query editorElement.config consistently in any scenario. See what I mean?

We could also change the public api method to preset, but I think it is important that things remain consistent here. I like config slightly better because we are talking about configurations when defining these.

Maybe we could go with presets indeed at the configuration level. So the lexxy configuration could expose two different structures:

{ global: new Configuration(...) presets: new Configuration({ default: { } ... }) }

So that we use preset at the public API (setter) and as a getter in the element.

And we make global a explicit configuration object to query like config.global.get("tagName") or whatever. And same for the presets: config.presets.get("default.whatever") or just config.presets.default to grab the properties we want for a preset.

So, for creating a editor-specific config we could do:

this.#config = new Configuration(lexxyConfig.presets.default) this.#config.merge(this.#overrides)

Thinking we could even extend the configuration constructor to admit a list of configurations (...configurations) that it will merge to avoid the explicit merge:

this.#config = new Configuration(lexxyConfig.presets.default, this.#overrides)

I think that is pretty clean. The code expresses what we are trying to do in a single line.

jorgemanrubia · 2025-12-18T16:57:20Z

src/editor/configuration.js

+
+  constructor(editorElement) {
+    this.#editorElement = editorElement
+    this.#config = new Configuration(this.#overrides)


I think like this should be something like

this.#config = new Configuration(lexxyConfig.get("default")) this.#config.merge(this.#overrides)

So that this.#overrides only returns the set of properties overridden by the editor. And then, you can use this.#config deterministically. I think the get having to check whether it is an override or not is a smell . Our config data structure allow overrides via merge, we should leverage that here, I believe.

In my mind the editor configuration would reflect any changes made to defaults/presets after editor instantiation, hence the reference directly in get.

But I realize now this is probably worse, not being able to assume a consistent config during an editor lifecycle.

Removing the runtime look-ups should make things much simpler!

Yeah, I think it is totally fine to assume that the properties are grabbed when the editor is instantiated, and subsequent changes won't be grabbed. That seems like a reasonable expectation to establish.

jorgemanrubia · 2025-12-19T08:48:04Z

src/elements/editor.js

    if (!this.cachedValue) {
      this.editor?.getEditorState().read(() => {
-        this.cachedValue = sanitize($generateHtmlFromNodes(this.editor, null))
+        this.cachedValue = sanitize($generateHtmlFromNodes(this.editor, null), { additionalAllowedTags: [ lexxyConfig.get("global.attachmentTagName") ] })


If this is set globally for dompurify, we don't need to do this right?

jorgemanrubia · 2025-12-19T08:49:42Z

src/nodes/action_text_attachment_node.js

  static importDOM() {
    return {
-      "action-text-attachment": (attachment) => {
+      [lexxyConfig.get("global.attachmentTagName")]: (attachment) => {


Checking these usages, I think making global a dedicated conttainer would read slightly better. And I think it is right to make global its own thing.

lexxyConfig.global.get("attachmentTagName")

jorgemanrubia · 2025-12-19T08:52:06Z

src/test/config/configuration.test.js

+import Configuration from "../../config/configuration"
+
+test("gets path", () => {
+  const c = new Configuration({


We normally avoid single-letter identifiers. Better to go with config or configuration.

jorgemanrubia · 2025-12-19T08:53:50Z

src/test/editor/configuration.test.js

@@ -0,0 +1,34 @@
+import { expect, test, vi } from "vitest"


Great to have JS tests available now 👍. Please configure an entry in Github actions and our local ci setup to run them as part of our pipeline.

jorgemanrubia · 2025-12-19T09:04:49Z

src/test/editor/configuration.test.js

+test("uses defaults", () => {
+  lexxyConfig.merge({
+    default: { singleLine: true }
+  })


Here we are modifying a global data structure as part of a single test run, which doesn't look great. Also, these tests are stubbing some internals. Ideally we would test the real thing here.

I think we could modify EditorConfiguration to receive as a second argument the presetConfiguration to use (with a default) so that, each test can use a fresh data structure for the defaults. I think these should be more like a black box: I have these defaults and I pass this element. I think we could also use jsdom to create a proper dom element from some HTML string for testing this? That way we could get rid of stubbing hasAttribute, which is an internal implementation detail.

…, merge all config constructor args into tree

zachasme · 2025-12-19T14:03:22Z

Thanks for the thorough feedback @jorgemanrubia! The PR might have been a bit too WIP, but the responses here are really clearing things up for me. It's slowly coming together nicely.

I think this is an important discussion:

{ toolbar: true }
// or
{
  toolbar: {
    bold: true
  }
}

Hmm not sure about this, it does not look super intuitive. I think it is important that we keep the core config abstraction lean and generic. I would rather interpret this at toolbar-rendering time: assume that everything is on unless there is a FALSE in the settings.

I agree we should assume everything is on by default, fully defined by the default preset. But I also think we should allow users to

configure({ default: { toolbar: false }})

In cases where a bool is overriding a hash, I think it would be valuable to recursively write the bool into nested hashes. It will complicate the merge logic, but it will make get super simple, we can more easily validate reads/writes and consumers of the config can rely on a known structure.

Alternatively, we can keep the config class completely generic and rely on the rest of the codebase to handle these differences.

We could also change the public api method to preset, but I think it is important that things remain consistent here. I like config slightly better because we are talking about configurations when defining these.

I think they both have merit. In isolation config= makes sense for the public API, it matches configure. But internally preset is more descriptive, and we avoid having both config and configuration referring to separate things. I also think it makes sense to introduce this as presets in the docs rather than configs.

Great to have JS tests available now 👍. Please configure an entry in Github actions and our local ci setup to run them as part of our pipeline.

I've also changed our workflow .yml to run on all pushes. Was there a specific reason we previously had:

on:
  pull_request:
  push:
    branches: [ main ]

jorgemanrubia

Looking tighter @zachasme 👏

jorgemanrubia · 2025-12-20T16:12:08Z

src/test/dom_helper.js

@@ -0,0 +1,5 @@
+import { JSDOM } from "jsdom"


I think I would prefer to keep test/ as a first level folder, parallel to src/. I think it is cleaner, so that it doesn't look like another system inside the source. I see that in trix it was inside, but in trix we also had a top level src/trix folder that we don't have here.

Also, I would move the dom_helper.js to a folder test/helpers.

I've moved them into test/javascript/. 👍

My thinking was we wanted them separate from the rails tests, but I agree this is cleaner.

jorgemanrubia · 2025-12-20T16:16:04Z

src/test/editor/configuration.test.js

+
+test("uses defaults", () => {
+  const element = createElement("<lexxy-editor></lexxy-editor>")
+  const config = new EditorConfiguration(element, "default")


With the new implementation, we don't have the problem I mentioned of having tests altering the same global structure over and over. I would remove the second param (preset) in the editor configuration constructor, since we don't need to override the config for testing purposes anymore. In the tests, I would insert that preset at the element level createElement("<lexxy-editor preset="simple"></lexxy-editor>") or just omit it there if you want to pass the default.

const element = createElement("<lexxy-editor></lexxy-editor>") const config = new EditorConfiguration(element) // or, for a specific one: const element = createElement("<lexxy-editor preset="simple"></lexxy-editor>") const config = new EditorConfiguration(element)

That way we would be testing the real thing.

Indeed. I kept the param because I had trouble getting jsdom to play nice with custom elements. I found a solution, though, and the param is gone.

jorgemanrubia · 2025-12-20T16:22:27Z

src/editor/configuration.js

+
+  get #overrides() {
+    const overrides = {}
+    for (const option of Object.keys(DEFAULT_PRESET)) {


I would rather keep the DEFAULT_PRESET as an internal constant and keep the configuration interface as the only way of interacting with the configurations. So I would use lexxyConfig.presets.get("default") instead of depending on the constant.

jorgemanrubia · 2025-12-20T16:25:51Z

src/config/lexxy.js

+  presets: new Configuration({ default: DEFAULT_PRESET })
+}
+
+export function configure(changes) {


Since this is a function to import, maybe configureLexxy instead of just configure would be more convenient.

The thing is that I would prefer an OO interface, so that you would do:

Lexxy.configure(...) Lexxy.config.global Lexxy.config.presets.get(...)

I think that feels more consistent and offers a proper namespace for other stuff we may add down the road. This way also you don't have to figure out how to rename lexxy functions and identifiers: lexxyConfig, lexxyConfigure... they are properly namespaced.

If we're talking public interface, we could keep the existing named exports and also provide a convenience default export, so the following would work the same:

import * as Lexxy from "lexxy" // same as import Lexxy from "lexxy" // usage Lexxy.configure(...) Lexxy.highlightAll()

We could also assign the same object to a global window.Lexxy. What do you think?

In terms of internal usage, how about exporting the following from config/lexxy.js?

export default { global, presets, configure(changes) { return presets.merge(changes) } } // usage import Lexxy from "./config/lexxy" Lexxy.global.get(..)

And then re-export Lexxy.configure for the public interface.

jorgemanrubia · 2025-12-20T16:31:24Z

src/elements/editor.js


  connectedCallback() {
    this.id ??= generateDomId("lexxy-editor")
+    this.config = new Configuration(this, this.preset)


Mentioned in other place, but passing an object and an attribute of that object as params feel off. It is an editor configuration: receiving the editor element should be enough. Notice the original mechanism I had suggested for tests was intended for tests only, as a mechanism to override the default param.

jorgemanrubia · 2025-12-20T16:34:07Z

src/helpers/string_helper.js

@@ -1,3 +1,11 @@
+export function camelize(value) {


this function is not used right? I think we could nix

jorgemanrubia · 2025-12-20T16:41:14Z

src/editor/configuration.js

+    this.#editorElement = editorElement
+    this.#config = new Configuration(
+      lexxyConfig.presets.get("default"),


Mentioned above: I would remove the preset second argument here. It is an editor config that receives an editor element, totally fine to query the editor element for its preset now:

this.#config = new Configuration( lexxyConfig.presets.get("default"), lexxyConfig.presets.get(editorElement.preset), this.#overrides )

jorgemanrubia · 2025-12-20T16:45:17Z

Alternatively, we can keep the config class completely generic and rely on the rest of the codebase to handle these differences.

I would wait to see if we need the extra complication. If someone sets that the toolbar is false, the editor won't configure any toolbar, so who is going to check nested toolbar properties? I would lean towards simple and generic unless the are specific reasons. Maybe there are specific scenarios where we need this right away, but what are those?

jorgemanrubia · 2025-12-20T16:49:48Z

On @zachasme and we also need to document the new configuration API in the README 🙏

zachasme · 2025-12-30T14:33:58Z

I would lean towards simple and generic unless the are specific reasons. Maybe there are specific scenarios where we need this right away, but what are those?

Good point, let's keep it simple.

we also need to document the new configuration API in the README 🙏

Almost there!

Initial attempt at config system

e1210b9

zachasme requested review from jorgemanrubia and samuelpecher December 18, 2025 10:39

zachasme added 2 commits December 18, 2025 11:42

Linting

fb652ef

Fix attribute parsing

a1a878a

samuelpecher reviewed Dec 18, 2025

View reviewed changes

Fix configure and listen (again)

3b6ba3c

jorgemanrubia reviewed Dec 18, 2025

View reviewed changes

No need for inheritance, move preset getter to editor level

52439ff

zachasme added 4 commits December 18, 2025 15:42

Refresh DOMPurify config on each call, extract deepMerge helper

232757c

Rely on JSON.parse when possible

eaaf451

Add vitest

8cc1485

Make fallback logic clearer

d37018b

jorgemanrubia reviewed Dec 18, 2025

View reviewed changes

jorgemanrubia reviewed Dec 19, 2025

View reviewed changes

Split presets/global into separate configs, use preset for global api…

ff0566b

…, merge all config constructor args into tree

zachasme force-pushed the config branch 4 times, most recently from f2e0451 to 322cbb7 Compare December 19, 2025 13:12

Run tests during local ci and github actions

c9d12d8

zachasme force-pushed the config branch from 322cbb7 to c9d12d8 Compare December 19, 2025 13:18

jorgemanrubia reviewed Dec 20, 2025

View reviewed changes

Configuration API #504

Are you sure you want to change the base?

Configuration API #504

Uh oh!

Conversation

zachasme commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

samuelpecher left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jorgemanrubia left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zachasme Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zachasme commented Dec 18, 2025

Uh oh!

jorgemanrubia commented Dec 18, 2025

Uh oh!

samuelpecher commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zachasme commented Dec 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

zachasme commented Dec 18, 2025 •

edited

Loading

zachasme Dec 18, 2025 •

edited

Loading

samuelpecher commented Dec 18, 2025 •

edited

Loading

jorgemanrubia Dec 19, 2025 •

edited

Loading

jorgemanrubia Dec 19, 2025 •

edited

Loading

jorgemanrubia Dec 19, 2025 •

edited

Loading