Replika Gambar Besar

Replika

Ini ialah rangka kerja yang membantu melaksanakan Perisian Local First. Git juga membantu mengatur tugasan yang disegerakkan melalui tolak dan tarik.

Replicache menyegerakkan data pelayan secara tidak segerak di belakang tabir, menghapuskan perjalanan pergi dan balik pelayan dan mendayakan perubahan UI serta-merta.

Bahagian Replika

Replikache terdiri daripada beberapa elemen.

Replika

Replika boleh dilihat sebagai stor Nilai Kunci dalam penyemak imbas yang merangkumi operasi seperti git secara dalaman. Tulis ke ingatan dahulu dan selaraskan kemudian.

Permohonan anda

Ini adalah aplikasi yang kami cipta, seperti aplikasi web. Ia adalah entiti yang menyimpan keadaan dalam Replicache. Mutator dan Langganan dilaksanakan untuk menukar dan bertindak balas kepada keadaan

Pelayan anda

Ia wujud untuk menyimpan data yang paling boleh dipercayai. Keadaan yang disimpan dalam pangkalan data yang disambungkan ke pelayan mengambil keutamaan berbanding keadaan dalam aplikasi.

Pelayan mesti melaksanakan tolak (hulu) dan tarik (hiliran) untuk berkomunikasi dengan Replika pelanggan.

• tolak(hulu): Replika menghantar perubahan pada titik akhir tolak. Mutator dilaksanakan pada pelayan serta aplikasi, dan titik akhir tolak ini melaksanakan mutator ini untuk menukar keadaan pangkalan data.

• tarik(hiliran): Apabila diminta secara berkala atau jelas, Replicache menghantar permintaan tarik ke pelayan. Pelayan mengembalikan perubahan yang diperlukan untuk klien menjadi sama dengan keadaan pelayan.

• poke: Walaupun pelanggan menghantar permintaan tarik secara berkala, untuk memaparkannya dalam masa yang lebih nyata, apabila terdapat perubahan pada pelayan, ia adalah isyarat bahawa pelayan memberi petunjuk kepada pelanggan untuk membuat permintaan tarik. Ia tidak membawa sebarang data.

Segerakkan

Aplikasi dan pelayan disegerakkan ke keadaan terkini. Gambar di bawah jelas menunjukkan proses ini. Ia menunjukkan proses menarik perubahan keadaan secara berkala daripada pelayan dan mengemas kini UI, dan cara perubahan keadaan pada klien mula-mula mengemas kini UI dan kemudian ditolak ke pelayan

Sumber

Pelanggan, ClientGroups, Caches

Replika dalam ingatan dipanggil Klien.

import {Replicache} from "replicache";

const rep = new Replicache({
  name: userID,
  ...
});

console.log(rep.clientID);

Biasanya terdapat satu pelanggan setiap ketikan. Pelanggan tidak menentu dan mengikuti kitaran hayat tab. Mempunyai ID pelanggan yang unik.

Kumpulan Pelanggan ialah satu set pelanggan yang berkongsi data setempat. Pelanggan dalam kumpulan pelanggan ini berkongsi keadaan walaupun semasa di luar talian.

Kumpulan Pelanggan menggunakan cache berterusan pada cakera yang dibezakan oleh parameter nama pembina Replicache. Semua pelanggan yang tergolong dalam Kumpulan Pelanggan dengan nama yang sama berkongsi cache yang sama.

Pandangan Pelanggan

Pelanggan mempunyai peta tersusun pasangan nilai utama dalam cache berterusan, yang dipanggil Paparan Pelanggan. Paparan Pelanggan ialah data aplikasi dan disegerakkan dengan data pelayan. Sebab ia dipanggil Paparan Pelanggan adalah kerana pelanggan yang berbeza mungkin mempunyai data pelayan dalam Paparan Pelanggan yang berbeza. Ini bermakna setiap pelanggan melihat status pelayan secara berbeza.

Mengakses Paparan Pelanggan adalah sangat pantas. Kependaman baca kurang daripada 1ms dan kebanyakan peranti mempunyai daya pemprosesan 500MB/s.

Adalah disyorkan agar anda membaca dan menggunakannya terus daripada Paparan Pelanggan daripada menyalin Paparan Pelanggan secara berasingan menggunakan useState dari tempat seperti React dan memuat naiknya ke memori. Apabila mutator menukar Paparan Pelanggan, langganan dicetuskan supaya UI dikemas kini

Langganan

Fungsi Langgan menerima hujah ReadTransaction dan melaksanakan bacaan daripada Replicache. Setiap kali langganan ini ketinggalan zaman disebabkan oleh perubahan dalam data replika, fungsi langgan dilakukan semula. Jika keputusan ini berubah, nilai akan dikemas kini dan UI turut dikemas kini.

Jika anda mengkonfigurasi UI melalui Langganan, anda boleh memastikannya sentiasa terkini.

import {Replicache} from "replicache";

const rep = new Replicache({
  name: userID,
  ...
});

console.log(rep.clientID);

Mutasi

Mutasi merujuk kepada tugas menukar data Replika. Subjek yang menerima mutasi dan sebenarnya menukar data dipanggil mutator.

Pada permulaan, beberapa Mutator didaftarkan dalam Replicache, tetapi ia sebenarnya hanya dinamakan fungsi. Kedua-dua createTodo dan markTodoComplete di bawah adalah mutator yang menukar data Replika melalui WriteTransaction.

const todos = useSubscribe(rep, async tx => {
  return await tx.scan({prefix: 'todo/'}).toArray();
});
return (
  <ul>
    {todos.map(todo => (
      <li key={todo.id}>{todo.text}</li>
    ))}
  </ul>
);

Mutator berfungsi seperti berikut. Apabila mutator beroperasi, data berubah dan langganan yang berkaitan dengannya dicetuskan, dan UI juga berubah.

const rep = new Replicache({
  ...
  mutators: {
    createTodo,
    markTodoComplete,
  },
});

async function createTodo(tx: WriteTransaction, todo: Todo) {
  await tx.set(`/todo/${todo.id}`, todo);
}

async function markTodoComplete(tx: WriteTransaction,
    {id, complete}: {id: string, complete: boolean}) {
  const key = `/todo/${id}`;
  const todo = await tx.get(key);
  if (!todo) {
    return;
  }
  todo.complete = complete;
  await tx.set(key, todo);
}

Secara dalaman, Mutator mencipta sesuatu yang dipanggil mutasi. Ia seperti rekod pelaksanaan, tetapi Replicache mencipta mutasi berikut.

await rep.mutate.createTodo({id: nanoid(), text: "take out the trash"});

Mutasi ini ditandakan sebagai belum selesai sehingga ia ditolak ke pelayan dan disegerakkan sepenuhnya.

Butiran Penyegerakan

Sekarang, berikut ialah butiran Penyegerakan, yang boleh dikatakan sebagai teras Replicache. Penyegerakan dilakukan pada pelayan.

Model Penyegerakan Replika

(Mulai sekarang, ungkapan 'keadaan' merujuk kepada keadaan data (ruang nilai kunci) yang terdiri daripada beberapa pasangan kunci dan nilai.)

Masalah Penyegerakan yang Replicache cuba selesaikan berlaku apabila berbilang pelanggan menukar keadaan yang sama pada masa yang sama dan keadaan berikut wujud.

1. Keadaan yang dimiliki pelayan adalah sumber kebenaran. Ia dinyatakan sebagai kanonik.
2. Perubahan dalam keadaan setempat pelanggan ditunjukkan serta-merta. Ini dipanggil spekulatif.
3. Pelayan mesti menggunakan perubahan tepat sekali dan hasilnya mesti boleh diramal. Perubahan yang digunakan pada pelayan mesti boleh digabungkan secara munasabah dengan perubahan setempat pada klien.

Item terakhir di antara ini ialah perubahan pelayan 'menggabungkan secara munasabah' dengan keadaan setempat, yang merupakan topik yang menarik. Untuk 'penggabungan rasional', situasi berikut mesti dipertimbangkan.

• Jika perubahan setempat masih belum digunakan pada pelayan. Dalam kes ini, anda perlu memastikan bahawa perubahan setempat tidak hilang daripada UI apl walaupun keadaan baharu diambil daripada pelayan. Selepas menerima keadaan baharu daripada pelayan, sebarang perubahan setempat sedia ada mesti dilaksanakan semula di atas keadaan pelayan.

• Apabila perubahan setempat yang dibuat pada klien telah pun dihantar ke pelayan dan ditunjukkan dalam keadaan pelayan. Dalam kes ini, berhati-hati untuk tidak menggunakan perubahan setempat dua kali. Perubahan setempat tidak boleh digunakan semula

• Jika ada pelanggan lain yang telah menukar keadaan pelayan untuk keadaan yang sama. Dalam kes ini, seperti dalam kes pertama, perubahan setempat mesti dibuat semula berdasarkan status yang diterima daripada pelayan. Walau bagaimanapun, kerana konflik mungkin berlaku ke atas sumber yang sama, logik gabungan mesti dirancang dengan teliti. Tulis logik ini di dalam Mutator.

Mari ikuti proses pengendalian Mutator.

Pelaksanaan tempatan

Mutator beroperasi secara tempatan dan nilai replika berubah mengikut logik mutator. Pada masa yang sama, pelanggan ini mencipta mutasi dengan mutationId yang meningkat secara berurutan. Mutasi dibariskan sebagai mutasi yang belum selesai

Tolak

Mutasi belum selesai dihantar ke titik akhir tolak (replicache-push) yang dilaksanakan pada pelayan.

mutasi mengubah keadaan kanonik dengan melaksanakan mutator yang dilaksanakan pada pelayan. Semasa menggunakan mutasi, id mutasi terakhir pelanggan ini dikemas kini dan menjadi nilai yang membolehkan anda mengetahui mutasi mana yang akan digunakan semula apabila pelanggan ini melakukan tarikan seterusnya

Mutasi yang belum selesai digunakan secara tempatan menjana hasil spekulatif dan mutasi yang digunakan pada pelayan menjana hasil kanonik. Mutasi yang digunakan pada pelayan disahkan dan tidak akan dilaksanakan secara setempat lagi. Walaupun mutasi yang sama mengembalikan hasil yang berbeza, keputusan kanonik pelayan diutamakan, jadi keputusan pelanggan berubah

Tarik

Replicache menghantar permintaan secara berkala ke titik akhir tarik (replikache-pull) untuk mendapatkan semula keadaan terkini dan mengemas kini UI.

Permintaan Tarik termasuk kuki dan clientGroupId serta mengembalikan kuki, tampung dan lastMutationIDChanges baharu.

Kuki digunakan untuk membezakan status pelayan yang dipegang oleh pelanggan. Sebarang nilai yang boleh menjejaki perbezaan keadaan pelayan dan klien adalah mencukupi. Anda boleh menganggapnya sebagai 'versi' global yang berubah apabila keadaan pangkalan data berubah. Sebagai alternatif, anda boleh menggunakan strategi kuki untuk menjejak julat data yang lebih khusus.

lastMutationIdChanges ialah nilai yang mewakili ID mutasi yang terakhir digunakan oleh pelayan untuk setiap pelanggan. Semua mutasi dengan mutationID yang lebih kecil daripada nilai ini tidak lagi dianggap belum selesai tetapi disahkan.

Pangkalan semula

Apabila pelanggan menerima tarikan, tampalan mesti digunakan pada negeri setempat. Walau bagaimanapun, kerana mutasi yang belum selesai akan menjejaskan keadaan tempatan semasa, tampung tidak boleh digunakan terus ke negeri tempatan. Sebaliknya, kembalikan mutasi tempatan yang belum selesai, gunakan tampalan yang diterima sebagai tarikan dahulu, kemudian gunakan semula mutasi belum selesai setempat.

Untuk mendayakan jenis buat asal dan aplikasi semula ini, Replicache telah direka bentuk serupa dengan Git. Anda boleh menganggap keadaan pelayan sebagai cawangan utama, dan keadaan diubah oleh mutasi yang belum selesai secara tempatan sebagai cawangan pembangunan, menerima tarikan daripada pelayan ke utama dan pangkalan semula berkembang ke utama.

Konflik yang mungkin timbul semasa rebase akan dibincangkan secara berasingan di bawah.

Cucuk

Poke, seperti yang dijelaskan di atas, ialah mesej pembayang yang pelayan memberitahu pelanggan untuk menarik.

Penyelesaian Konflik

Konflik gabungan tidak dapat dielakkan dalam sistem yang diedarkan seperti Replicache. Penggabungan adalah perlu semasa proses tarik dan tolak. Penggabungan hendaklah dilakukan dengan cara yang menjadikan hasil gabungan boleh diramal dan sesuai dengan tujuan apl.

Jika ia adalah apl tempahan bilik persidangan, hanya satu permintaan perlu diluluskan apabila konflik berlaku. Oleh itu, anda mesti menggunakan kaedah gabungan yang hanya meluluskan pelanggan yang telah membuat tempahan terlebih dahulu.

Sebaliknya, jika ia adalah apl Todo, tujuan senarai Todo ialah kedua-dua perubahan diluluskan walaupun penambahan berlaku pada masa yang sama.

Konflik Gabungan berlaku dalam dua situasi berikut.

1. Apabila perubahan setempat akan digunakan pada pelayan. Ini kerana status apabila digunakan secara setempat dan status apabila digunakan pada pelayan mungkin berbeza.

2. Apabila rebasing. Ini kerana status mungkin berbeza apabila digunakan.

Replicache mengiktiraf bahawa kaedah gabungan mesti dilaksanakan secara berbeza bergantung pada tujuan apl, jadi ia membolehkan pembangun melaksanakannya. Pembangun boleh melaksanakan logik ini melalui Mutator.

Atas ialah kandungan terperinci Replika Gambar Besar. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!