@webwriter/ww-quiz v0.6.2

Quiz Package for WebWriter

How to handle web components

1. Use the .wc.svelte file extension so that Vite can pick it up.
2. The file should begin with <svelte:options tag="tag-name" /> where tag-name is how you want the custom element to be named.
3. Remember that the attributes can be tampered with by the user! Make sure you parse them accordingly.

4. To avoid mess, never use components you defined as custom elements as Svelte components! Instead, do the following:

   <!-- MyComponent.wc.svelte: -->
   <svelte:options tag="my-component" />
   <!-- ... -->
   
   <!-- A different component where you want to use MyComponent: -->
   <script>
     import './path/to/MyComponent.wc.svelte';
   </script>
   
   <my-component />

How to apply styles

We rely on Vite and svelte-preprocess for styling. Adding SCSS styles to a component is as easy as that:

<style lang="scss">
  /* Your SCSS here */
</style>

You can also refer to an external file:

<style src="./style.css"></style>

The styles will be scoped to the component just as you would expect. Note that using a relative path starting with . is required.

Global Styles

We used src/global.scss for global styling. The styles are loaded from the shell component and injected into the shadow DOM.

How editable and printable are handled

In production mode, we expect editable and printable as attributes to the shell widget. We treat both as boolean attributes, meaning that the sole presence of an attribute should be enough to consider the corresponding property's value to be true. This holds irrespective of the attribute's string value, including when it is set to "false". This is the standard behavior for boolean attributes in the web platform, see for example how Lit treats them.

In development mode, the properties are completely replaced by devEditable and devPrintable so as to enable switching between modes easily.

The values all components should actually be interested in are kept in stores exported by global.ts. The stores should only be written to from inside the shell widget's code.

Why not just couple editable and printable so that they are never true at the same time?

We want the properties to reflect the attributes whenever possible, so messing with the properties is a bad idea (it is one of the reasons why we have introduced devEditable and devPrintable).

We also do not want to make the stores depend on each other because it would mean that we have two sources of truth. It would make us have to update the properties in response to store changes, but stores themselves depend on properties, so we would end up with cyclic dependencies that are really nasty to deal with.

The solution is simple: we just prioritize print mode over edit mode. By doing that, we can ensure that both store values are never true at the same time while they only depend on property values which are not coupled in any way.

Verification

Every component gets passed a validate prop. True if widgets are in validation mode.

Registration of new Widgets

Insert new Widget in ShellWidget.wc.svelte into the Array possibleComponents.

Shoelace import

We created svelte components for our used Shoelace components. Used due to svelte specific features like two-way binding and intellisense. We used the forward events builder to forward all events from the web component.