tchak

Some random follow up thoughts on todays discussion with @jo_liss, @terzicigor and @dgeb

After more thoughts it seems to me that on the backend it’s almost unavoidable to have commits built in to the database, or at last to have some kind of a persistence layer on top of the database. Basically if someone or something changes the database and do not update "commits table", the system will become inconsistent. So are we trying to invent a new database?

On most backend apis there is a serialization/presentation layer on top of the database, which means api objects != database objects. It means what we were describing today, is not a drop in replacement for REST apis in the form they exists today. Firebase is a “dumb store”, this is why they can be smart about synchronization.

We had only little talk about multiuser scenarios. Or even anonymous users. Seems like a lot to think about here. There should be a way to subscribe to some subsets of data with the right authorizations. What happens if authorizations c

tchak

Pain à Hamburger

Ingrédients / pour 6 personnes

• 500 g de farine (T55 si possible)
• 1 sachet de levure de boulangerie déshydratée
• 10 g de sucre
• 80 g de beurre coupé en dés
• 320 g de lait tiède (35°C)
• 1 jaune d'oeuf
• graines de sésame

tchak

Ember data will define several type of errors :

DS.AdapterError < Ember.Error
DS.InvalidError < DS.AdapterError
DS.TimeoutError < DS.AdapterError
DS.AbortError < DS.AdapterError

An DS.AdapterError has a errors property that contains errors payload as defined in json-api

tchak

Answer to @patcito tweets about @angualrjs vs @emberjs

What you call "Model Driven View" is actualy kind of a shell for three spec. This is from the link you sent me a while ago about "Model Driven View" status (mdv) :

The first piece (a) was DOM Mutation Observers (which replace the long-deprecated Mutation Events). This has already being specified in DOM4 and is currently shipping in both Chrome and Firefox.

DOM Mutation Observers

tchak

module LocalizedJob
  
  module InstanceMethods
    def send_later_with_i18n(method, locale, *args)
      locale ||= I18n.locale
      job = LocalizedJob::LocalizedMethod.new(self, method.to_sym, args)
      job.locale = locale
      Delayed::Job.enqueue job
    end
  end

tchak

<?php
class DemarchesSimplifiees {
    function __construct($token) {
        $this->token = $token;
    }

    function procedure($procedure_id) {
        return $this->request("procedures/$procedure_id");
    }

tchak

import Orbit, {
  Source,
  SourceSettings,
  RecordOperation,
  buildTransform
} from '@orbit/data';
import {
  JSONAPISerializer,
  JSONAPISerializerSettings,
  ResourceOperationsDocument

tchak

Is it possible to use Orbit.js as a simple fetching client with a json:api server? The answer is yes, with certain caveats. First one is you still need to write a schema.

import { Schema } from '@orbit/data';
import JSONAPISource from '@orbit/jsonapi’;

const schema = new Schema({
  models: {
    article: {
      attributes: {

tchak

class MyMemorySource extends MemorySource {
  async _query(query, hints) {
    if (hints && hints.data) {
      let identities = hints.data.primaryData ? hints.data.primaryData : hints.data;
      let data;
      if (Array.isArray(identities)) {
        data = this._cache.query(q => q.findRecords(identities));
      } else {
        data = this._cache.query(q => q.findRecord(identities));
      }

tchak

import { Schema } from '@orbit/data';
import { JSONAPISerializer } from '@orbit/jsonapi';
import { Dict } from '@orbit/utils';

export interface JSONSchemaType {
  type: 'object' | 'string' | 'number' | 'boolean';
  pattern?: string;
}

export interface JSONSchemaRef {