habdelra

REMIX EXAMPLE PROJECT

Remix example project is present when Remix loads very first time or there are no files existing in the File Explorer. 
It contains 3 directories:

1. 'contracts': Holds three contracts with different complexity level, denoted with number prefix in file name.
2. 'scripts': Holds two scripts to deploy a contract. It is explained below.
3. 'tests': Contains one test file for 'Ballot' contract with unit tests in Solidity.

SCRIPTS

habdelra

The following cs fields exist on cards:

- csRealm: The realm that the card currently resides in.

- csId: The csId distinguishes the card within its originalRealm. In some cases
  it may be chosen by the person creating the card. In others it may be
  chosen by the hub.
  
- csOriginalRealm: The realm that the card was first created in. Often times 
  this value will be undefined, when this value is undefined that means that the 

habdelra

Card creation
POST http://localhost:3000/api/realms/first-ephemeral-realm/cards

Request Body:
{
  "data": {
    "type": "cards",
    "attributes": {
     "csFieldSets": {
        "embedded": [

habdelra

import Service from '@ember/service';

export default class DataService extends Service {
  cache = new Map();

  async getCard(id /*: string */, format /*: string*/) {
    // if the card already exists in the cache, just return cached card
    // return Card instance
  }

habdelra

// This file lives in an npm module with the name of 'article-card' in a cards.js file. 
// (I think just using index.js might be a good idea too--i can go either way here)

const JSONAPIFactory = require('@cardstack/test-support/jsonapi-factory');

module.exports = function() {
  let factory = new JSONAPIFactory();

  // the card ID specified only needs to speify the last part of the multi-part ID.
  // the rest of the card ID parts are derived from the package name.

habdelra

// In this example we show how fields are actually cards, and we customize a field by adopting a string-field card.

{
  data: {
    type: 'cards'
    id: '@acme/ticket-tools::ticket-card:123',
    ... 
  },
  included: [
  

habdelra

// In this example we control the types of cards that are allowed in the event relationship
// using the "related-cards" relationship that hangs off of the field.

{
  data: {
    type: 'cards'
    id: '@acme/ticket-tools::ticket-card:123',
    ... 
  },
  included: [

habdelra

{
  data: {
    type: 'cards'
    id: '@acme/ticket-tools::ticket-card:123',
    attributes: {
      'edit-template': `
        {{delegate-to content.event}} {{!-- framework decides the format to use, appears as embedded until a user clicks on it, for example --}}
        {{delegate-to content.price}}
      `,
      'isolated-template': `

habdelra

// Card Adoption example
{
  data: {
    type: 'cards',
    id: '@foobar/events-are-us::event-cards::emberconf-2020',
    attributes: {
       // no need to define templates and components if we have not changed it
       // when hub instantiates this card it will traverse the "adopts" graph to get the template and components for this card
       // when there is more than 1 adopted card, then you must define your card's templates and components here
       // Also use similar approach as ember in terms of not having a component js, where the component is just a glimmer comnponent of the outer HTML of the template,

habdelra

// Sample Ticket card 
// A card can represent both its schema and its data in a single document

{
  data: {
    type: 'cards'
    id: '@acme/ticket-tools::ticket-card:123',
    attributes: {
      'suggested-name': 'ticket',
      'edit-template': `