davismj

<number-pad {...Astro.props}></number-pad>
<script>
	import { FASTElement, css, customElement, html } from "@microsoft/fast-element";
	import styles from './number-pad.scss?inline';

	const template = html<NumberPad>`
		<div class="number-pad" @click="${(x, c) => x.handleClick(c.event)}">
			<div class="number-pad-row">
				<span role="button">1</span>
				<span role="button">2</span>

davismj

---
import { parseBody } from 'parse-body'
export const partial = true

const params = await parseBody(Astro.request.body)
---

davismj

* {
  box-sizing: border-box;
  padding: 0;
  margin: 0;
}
.container {
  position: relative;
  overflow: hidden;
  max-height: 100vh;
  max-width: 100vw;

davismj

* {
  box-sizing: border-box;
  padding: 0;
  margin: 0;
}
.container {
  position: relative;
  overflow: hidden;
  max-height: 100vh;
  max-width: 100vw;

davismj

<template>
  <style>
    * {
      box-sizing: border-box;
      padding: 0;
      margin: 0;
    }
    .container {
      position: relative;
      overflow: hidden;

davismj

<template>
  <require from="./registration-form"></require>
  
  <registration-form></registration-form>
</template>

davismj

I've identified two patterns that I believe to be best practices. First, always protect the enumerable properties of your models. Next, always use factories to construct your models. These are not specifically related to model mapping, but these strategies will significantly reduce the complexity of mapping models and may even eliminate the need for special handling in many cases.

Best Practices:

1. Protect your enumerable properties
2. Use factories, not constructors

Protect your enumerable properties

First, some terminology. The words "view-model" in Aurelia is one component of the MVVM pattern, also known as the MVC pattern. In this pattern, you would have a a view that describes how everything should be displayed, a view-model that captures state and behavior of the view, and a model that provides data that is displayed and modified in the view. The view tends to be clear, but the line between view and view-model can be tricky. In general, your model should always represent the data from th

davismj

<template>
  <require from="custom-table"></require>
  <custom-table items.bind="data">
    <template replace-part="row">
      <tr>
        <th>${item.v}</th>
        <th>${item.a}</th>
        <th>${item.k}</th>
      </tr>
    </template>

davismj

<template>
  app
  <router-view></router-view>
</template>

davismj

<template>
  <require from="custom-table"></require>
  <custom-table items.bind="data">
    <template replace-part="row">
      <tr>
        <th>${item.v}</th>
        <th>${item.a}</th>
        <th>${item.k}</th>
      </tr>
    </template>