Feliz: panduan pihak ketiga

Ini terlihat fantastis IMHO.

Terima kasih! Untung kamu suka :smile:

Apakah ini mudah diperluas untuk hal-hal pihak ke-3, seperti Material-UI?

Tentu saja, tetapi pendekatannya sedikit berbeda karena kami tidak menggunakan serikat pekerja yang didiskriminasi. Saya mencoba menulis sesuatu ketika waktu mengizinkan tetapi idenya adalah Anda pada dasarnya memiliki dua opsi:

• 1) Perluas tipe statis prop dengan lebih banyak fungsi
• 2) Buat tipe statis prop yang serupa, khusus untuk perpustakaan Anda (mungkin Mui ) yang memiliki semua properti yang dibutuhkan Mui. Anda bahkan dapat membuat alias prop dengan Mui dan memperluas Mui dengan properti dan fungsi khusus Mui (kelebihan beban).

Memperluas adalah yang sederhana seperti:

type prop with
  static member hello (value: string) = Interop.mkAttr "hello" value 

Apakah ini "bentuk akhir" dari perpustakaan dan cara untuk memperluasnya, masih dalam pertimbangan karena saya ingin mencobanya terlebih dahulu dengan membangun perpustakaan pihak ke-3 dan melihat bagaimana kelanjutannya

Terima kasih! Saya sudah berjalan dengan baik dengan menguji sesuatu untuk MUI, hanya untuk sebagian kecil dari API, untuk melihat cara kerjanya. Mungkin akan dibagikan suatu saat selama minggu/-akhir, akan sangat bagus jika Anda bisa melihatnya hanya untuk melihat apakah saya berada di jalur dan mengikuti semangat Feliz. Sepertinya sukses sejauh ini!

Namun, saya belum memperluas tipe prop yang ada. Saya telah mendefinisikan tipe prop terpisah di namespace lain ( Feliz.MaterialUI ). Bekerja tampaknya hebat; Anda tentu saja mendapatkan akses ke semua anggota dari semua jenis yang cocok jika Anda membuka Feliz dan Feliz.MaterialUI .

Saya memiliki tipe Mui yang sesuai dengan Html dan berisi komponen yang sebenarnya.

(Saat ini saya telah menempatkan props khusus komponen dalam submodul terpisah dari prop , seperti yang disebutkan di #13.)

Titik perbaikan yang mungkin dalam Feliz adalah memiliki reactElement dan createElement yang tidak menerima string , tetapi ReactElementType (saya pikir). sehingga kita dapat memanggil createElement (importDefault "@material-ui/core/Button") . Saya telah membuat dua pembantu ini sendiri saat ini.

Omong-omong, haruskah semua anggota inline ? Apa pro/kontranya? Saya perhatikan Anda tidak menggunakan inline di atas, tetapi semua yang ada di Feliz adalah inline .

Terima kasih! Saya sudah berjalan dengan baik dengan menguji sesuatu untuk MUI, hanya untuk sebagian kecil dari API, untuk melihat cara kerjanya. Mungkin akan dibagikan suatu saat selama minggu/-akhir, akan sangat bagus jika Anda bisa melihatnya hanya untuk melihat apakah saya berada di jalur dan mengikuti semangat Feliz. Sepertinya sukses sejauh ini!

Itu luar biasa! Saya pasti akan senang untuk melihatnya jika Anda

Namun, saya belum memperluas tipe prop yang ada. Saya telah mendefinisikan tipe prop terpisah di namespace lain (Feliz.MaterialUI). Bekerja tampaknya hebat; Anda tentu saja mendapatkan akses ke semua anggota dari semua jenis yang cocok jika Anda membuka Feliz dan Feliz.MaterialUI.

Saya memiliki tipe Mui yang sesuai dengan Html dan berisi komponen yang sebenarnya.

Itulah yang akan saya lakukan untuk Mui

(Saat ini saya telah menempatkan props khusus komponen dalam submodul prop yang terpisah, seperti yang disebutkan di #13.)

Masuk akal bagi Mui karena banyaknya pilihan yang kamu miliki

Titik perbaikan yang mungkin dalam Feliz adalah memiliki reactElement dan createElement yang tidak menerima string, tetapi ReactElementType (saya pikir). sehingga kita dapat memanggil createElement (importDefault "@material-ui/core/Button"). Saya telah membuat dua pembantu ini sendiri saat ini.

Saya meninjau anggota yang saya gunakan di modul Interop , saya baru saja mengekspos apa pun yang saya gunakan di perpustakaan, akan dipertimbangkan kembali untuk rilis stabil

Omong-omong, haruskah semua anggota inline? Apa pro/kontranya? Saya perhatikan Anda tidak menggunakan inline di atas, tetapi semua yang ada di Feliz inline.

Saya seharusnya menggarisbawahi anggota yang diperluas di atas!

Aturan praktisnya adalah: jika nilai properti primitif seperti string/int/bool/enum maka inline properti tetapi jika properti Anda menghitung nilai berdasarkan input maka lebih baik tidak inline karena setiap kali pengguna memanggil fungsi sebaris, seluruh badan fungsi digarisbawahi di tempat pemanggilan itu, jadi jika pengguna menggunakan fungsi yang sama 10 kali di seluruh aplikasi, badan fungsi dikompilasi sebaris 10 kali alih-alih didefinisikan sekali dan direferensikan 10 kali

Aturan praktisnya adalah: jika nilai properti primitif seperti string/int/bool/enum maka inline properti tetapi jika properti Anda menghitung nilai berdasarkan input maka lebih baik tidak inline karena setiap kali pengguna memanggil fungsi sebaris, seluruh badan fungsi digarisbawahi di tempat pemanggilan itu, jadi jika pengguna menggunakan fungsi yang sama 10 kali di seluruh aplikasi, badan fungsi dikompilasi sebaris 10 kali alih-alih didefinisikan sekali dan direferensikan 10 kali

Bagus untuk mengetahui! Tapi (dalam konteks Fabel) kenapa pertama-tama sebaris? Apa manfaat dari fungsi/metode "sederhana"?

• Ukuran bundel: jika fungsi-fungsi ini tidak digunakan (dan ada 100-an), mereka tetap dikompilasi, menggembungkan ukuran bundel AFAIK (dampaknya tentu saja masih relatif terhadap ukuran total aplikasi)
• Argumen tipe generik: tidak relevan untuk Feliz tetapi dalam konteks Fable, fungsi generik dengan argumen tipe generik tidak akan dikompilasi jika tempat pemanggilan tidak digariskan (semua argumen tipe generik harus diselesaikan secara statis pada waktu kompilasi) kecuali untuk kasus khusus di mana Anda dapat menggunakan [<Inject>] ITypeResolver<'t> sebagai argumen opsional dari kelas statis (hanya perpustakaan yang sangat khusus yang menggunakan fitur ini, lihat Fable.SimpleJson/Thoth.Json)

Saya pikir babel melakukan pengguncangan pohon dan menghapus fungsi yang tidak digunakan saat Anda membuat bundel produksi. Inlining akan mengalahkan itu.

@Luiz-Monad Apakah Anda kemudian mengatakan bahwa, idealnya, tidak ada apa pun di Feliz yang harus digarisbawahi? Inlining karena alasan ukuran bundel itu kontra-produktif?

@Luiz-Monad Apa yang Anda katakan akan luar biasa! Setidaknya jika kompilasi bekerja seperti itu. Berikut adalah contoh yang dapat Anda coba dengan REPL:

module App

type prop = 
  // does useless stuff
  static member f() = 
    [ 1 .. 100 ]
    |> List.map (fun x -> x * 20)
    |> List.collect (fun n -> [n; n])
    |> List.fold (+) 0

  // does useless stuff
  static member inline k() = 
    [ 1 .. 100 ]
    |> List.map (fun x -> x * 20)
    |> List.collect (fun n -> [n; n])
    |> List.fold (+) 0

  static member g() = 1

let value = prop.g()

printfn "%d" value

Di mana prop berisi:

• f() berisi badan fungsi -> tidak sebaris dan juga tidak digunakan
• k() berisi badan fungsi -> sebaris tetapi tidak digunakan
• g() berisi fungsi -> tidak sebaris dan digunakan

Anda akan berpikir bahwa f() dan g() tidak akan dikompilasi tetapi bukan itu masalahnya, f() (tidak inline dan tidak digunakan) tetap dikompilasi, tetapi k() (sebaris, tidak digunakan) tidak masuk ke dalam bundel yang dikompilasi

import { fold, collect, map, ofSeq, ofArray } from "fable-library/List.js";
import { type } from "fable-library/Reflection.js";
import { rangeNumber } from "fable-library/Seq.js";
import { toConsole, printf } from "fable-library/String.js";
import { declare } from "fable-library/Types.js";
export const prop = declare(function App_prop() {});
export function prop$reflection() {
  return type("App.prop");
}
export function prop$$$f() {
  return fold(function folder(x$$1, y) {
    return x$$1 + y;
  }, 0, collect(function mapping$$1(n) {
    return ofArray([n, n]);
  }, map(function mapping(x) {
    return x * 20;
  }, ofSeq(rangeNumber(1, 1, 100)))));
}
export function prop$$$g() {
  return 1;
}
export const value = prop$$$g();
toConsole(printf("%d"))(value);

Memang berhasil, tetapi Anda perlu mengkonfigurasi webpack untuk melakukan itu, karena apa yang dimaksud dengan goyangan pohon bukanlah dongeng itu sendiri, sehingga tidak akan berfungsi di REPL.

Sebelum

/// Library.fs
module Library

type prop = 
    // does useless stuff
    static member f() = 
      [ 1 .. 100 ]
      |> List.map (fun x -> x * 20)
      |> List.collect (fun n -> [n; n])
      |> List.fold (+) 0

    // does useless stuff
    static member inline k() = 
      [ 1 .. 100 ]
      |> List.map (fun x -> x * 20)
      |> List.collect (fun n -> [n; n])
      |> List.fold (+) 0


type AppMain =
    static member g() = 1

//// App.fs
module App

let value = Library.AppMain.g ()

printfn "%d" value

Setelah

  declare(function Library_prop() { 
     // see its empty, this weren't removed too because of `keep_classnames: true, keep_fnames: true ` in the terser plugin
  });
  declare(function Library_AppMain() {
  });
  !function toConsole(arg) {
    return arg.cont(function (x) {
      console.log(x)
    })
  }(printf('%d')) (1),
  __webpack_require__.d(__webpack_exports__, 'value', function () {
    return 1
  })

Juga, ada peringatan untuk pengujian Anda, file entri agak khusus karena fungsinya tidak dihapus. (Saya kira ada sesuatu yang harus dilakukan dengan inisialisasi kelas statis, sesuatu harus memanggil konstruktor penginisialisasi statis untuk melakukan efek samping pada modul)

Lihat repositori ini yang saya buat untuk pengujian ini https://github.com/Luiz-Monad/test-tree-shaking

Terima kasih banyak untuk contoh repo! Saya pasti akan menyelidiki ini lebih lanjut untuk melihat apakah inlining benar-benar melakukan sesuatu yang berguna dalam konteks Feliz

Saya pasti akan menyelidiki ini lebih lanjut untuk melihat apakah inlining benar-benar melakukan sesuatu yang berguna dalam konteks Feliz

Keren, menantikan untuk mendengar apa yang Anda temukan :)

Itu luar biasa! Saya pasti akan senang untuk melihatnya jika Anda

Silakan periksa cabang feliz di cmeeren/fable-elmish-electron-material-ui-demo .

Sebagian besar kode dibuat secara otomatis berdasarkan dokumen API (HTML). Ada proyek generator (jelek dan retas, tetapi menyelesaikan pekerjaan) dan proyek untuk binding yang sebenarnya. Dalam proyek renderer, hanya App.fs yang telah dikonversi untuk menggunakan binding gaya Feliz yang baru.

Silakan lihat saat Anda menyukainya, dan beri tahu saya pendapat Anda dan jika Anda memiliki pertanyaan.

@cmeeren Terlihat sangat bagus dan jauh lebih baik daripada API IMHO saat ini tetapi apakah masih agak sulit dibaca tetapi itu lebih merupakan sifat perpustakaan itu sendiri, ia memiliki banyak bagian yang sangat spesifik yang harus Anda ketahui. Saya pikir ada bagian yang bisa diperbaiki, ambil contoh ini:

Mui.appBar [
  prop.className c.appBar
  prop.appBar.position.fixed'
  prop.children [
    Mui.toolbar [
      prop.children [
        Mui.typography [
          prop.typography.variant.h6
          prop.typography.color.inherit'
          prop.text (pageTitle model.Page)
        ]
      ]
    ]
  ]
]

Versi sempurna pribadi saya dari cuplikan ini adalah mengubahnya menjadi yang berikut:

Mui.appBar [
  AppBar.className c.appBar
  AppBar.position.fixed'
  AppBar.children [
    Mui.toolbar [
      Toolbar.children [
        Mui.typography [
          Typography.variant.h6
          Typography.color.inherit'
          Typygraphy.text (pageTitle model.Page)
        ]
      ]
    ]
  ]
]

Dengan cara ini mudah untuk menemukan elemen Mui karena Anda hanya dapat "melewati" Mui dan setelah Anda menemukan elemen Anda ( appBar ), Anda dapat "melewati" nama modul ( AppBar ) untuk menentukan properti dan semacamnya

Mungkin menyimpan AppBar sebagai huruf kecil juga

Saya pikir Anda mendapatkan idenya tetapi lebih tepatnya, sintaks umum API ini adalah sebagai berikut di mana {Element} adalah elemen reaksi:

Mui.{element} [
  {Element}.{propName}.{propValue}
  {Element}.children [
    Mui.{otherElem} [
      {OtherElem}.{propName}.{propValue}
      // etc.
    ]
  ]
]

Apa yang Anda pikirkan tentang ini? API ini juga mengilhami perpustakaan ide-ide elemen sederhana yang luar biasa jika Anda ingin melihat implementasi yang nyata

Saya pikir itu sempurna, dan saya ingin mendapatkan pendapat Anda. Saya awalnya memilih untuk memiliki semuanya di bawah prop karena itulah cara kerja perpustakaan utama, tetapi tentu saja Anda tidak benar-benar memiliki alat peraga khusus komponen, sedangkan MUI memiliki lebih banyak lagi, lebih sedikit, hanya alat peraga khusus komponen.

Saya pikir berpegang pada nama modul huruf kecil mungkin terlihat terbaik (dan menyimpan penekanan tombol tambahan), tapi saya terbuka untuk argumen tandingan.

Bagus bahwa saya telah membuat hal ini secara otomatis, yang membuatnya mudah untuk diubah.

Saya akan memperbarui dan memberi tahu Anda.

Namun, ada satu hal khusus yang ingin saya dapatkan pendapatnya. Ini adalah barang ClassName . Kait makeStyles mengembalikan objek dengan properti yang sama dengan objek yang dilewatinya, tetapi setiap elemen (JSS) telah diganti dengan string, yang merupakan nama kelas yang akan digunakan (dan dapat diteruskan ke mis. prop.className ).

Sekarang, tidak ada cara untuk mengetiknya di F#, jadi saya harus bekerja dengan apa yang saya miliki. Biasanya semua props dari objek style adalah IStyleAttribute list . Ini berarti bahwa saya dapat menambahkan kelebihan untuk prop.className yang menerima IStyleAttribute list , yang tentu saja bohong karena pada saat runtime itu adalah sebuah string. Jika Anda benar-benar melewatinya IStyleAttribute list itu akan gagal. Selain prop.className , ini juga berlaku untuk semua classes.<element>.<classesName> (digunakan dalam <element>.classes [ ... ] ). Mereka juga menerima nama kelas (string).

Apa yang telah saya lakukan, seperti yang Anda lihat, adalah untuk "memerlukan" semua properti IStyleAttribute list dari objek gaya untuk dibungkus asClassName , yang pada dasarnya hanya membuka kotak ke IClassName (proxy untuk string , jika Anda mau). Dan kemudian saya telah menambahkan kelebihan ke prop.className accept $ IClassName , dan membuat semua classes props menerima IClassName . Saya suka itu diketik lebih kuat, tapi saya tidak suka itu membutuhkan pengetikan ekstra ( asClassName untuk setiap aturan CSS tingkat atas). Kompilator akan mengeluh jika Anda melewatkannya, tetapi tidak memberi tahu Anda apa yang harus dilakukan, dan masih ada noise tambahan.

Apakah Anda punya masukan tentang ini?

Juga, saya perhatikan ini:

f# listItem.divider ((page = Home))

Di sini, tanda kurung ganda diperlukan, karena jika tidak, F# menafsirkannya sebagai mencoba memanggil listItem.divider dengan parameter page $ (tidak ada) yang disetel ke Home (bukan value Parameter page = Home ). Apakah Anda melihat cara untuk menghindarinya?

Halo @cmeeren , pertama-tama, saya sangat menyukai sintaks ini:

Mui.appBar [
  prop.className c.appBar
  appBar.position.fixed'
  appBar.children [
    Mui.toolbar [
      toolbar.children [
        Mui.typography [
          typography.variant.h6
          typography.color.inherit'
          prop.text (pageTitle model.Page)
        ]
      ]
    ]
  ]
]

Itu hanya terlihat sangat bersih dan sangat sederhana! Meskipun jika saya jadi Anda, saya mungkin akan menduplikasi beberapa fungsi generik prop menjadi props khusus komponen seperti appBar.className alih-alih (atau bersama) prop.className sehingga mereka semua terlihat simetris tetapi yang lebih penting untuk memberikan IClassName kelebihan ke komponen khusus Mui daripada prop.className generik yang mengambil string karena makeStyles juga khusus Mui membangun dan masuk akal bahwa itu hanya akan berlaku untuk komponen Mui.

Saya pikir Anda menangani makeStyles dengan cara terbaik, setidaknya saat ini saya tidak dapat memikirkan cara yang lebih baik (Meskipun saya bukan penggemar berat asClassName , mungkin Styles.createClass bukan? terserah Anda).

Adapun listItem.divider ((page = Home)) itu rumit, Anda bisa menambahkan fungsi dummy let when (x: bool) = x tapi itu hanya noise. Saya pikir yang terbaik adalah mengajukannya sebagai bug kompiler karena saya tidak dapat memikirkan alasan mengapa kompiler F # tidak dapat menyelesaikan kelebihan fungsi yang tepat, saya belum mencoba sendiri tetapi saya akan memeriksanya ketika waktu mengizinkan

Terakhir, saya tidak responsif seperti biasanya minggu ini karena saya sedang berlibur sekarang, jadi saya mungkin tidak bisa membaca/memeriksa semuanya dll.

Meskipun jika saya jadi Anda, saya mungkin akan menduplikasi beberapa fungsi generik prop menjadi alat peraga khusus komponen seperti appBar.className alih-alih (atau bersama) prop.className sehingga mereka semua terlihat simetris tetapi yang lebih penting untuk memberikan IClassName kelebihan ke komponen khusus Mui daripada prop.className generik yang menggunakan string karena makeStyles juga khusus Mui membangun dan masuk akal bahwa itu hanya akan berlaku untuk komponen Mui.

Lihat sekarang :) Saya telah melakukan peningkatan dan perluasan drastis dalam beberapa hari terakhir, hanya mendorongnya (belum selesai, saat ini saya sedang memeriksa semua komponen MUI untuk memverifikasi dan meningkatkan alat peraga yang dihasilkan).

Saya pikir Anda menangani makeStyles dengan cara terbaik, setidaknya saat ini saya tidak dapat memikirkan cara yang lebih baik (Meskipun saya bukan penggemar berat asClassName , mungkin Styles.createClass bukan? terserah Anda).

Saya ingin membuatnya sesingkat mungkin karena akan sering digunakan, tetapi saya terbuka untuk nama lain. Meskipun saya memiliki setengah pikiran untuk hanya memiliki kelebihan IStyleAttribute list . Ini akan menghilangkan sedikit noise yang berpotensi, dan saya ragu itu akan sangat berbahaya meskipun secara teknis dapat digunakan secara tidak benar.

Adapun listItem.divider ((page = Home)) itu rumit, Anda bisa menambahkan fungsi dummy let when (x: bool) = x tapi itu hanya noise. Saya pikir yang terbaik adalah mengajukannya sebagai bug kompiler karena saya tidak dapat memikirkan alasan mengapa kompiler F # tidak dapat menyelesaikan kelebihan fungsi yang tepat, saya belum mencoba sendiri tetapi saya akan memeriksanya ketika waktu mengizinkan

Terima kasih, saya telah mengajukan masalah sekarang: https://github.com/dotnet/fsharp/issues/7423

Terakhir, saya tidak responsif seperti biasanya minggu ini karena saya sedang berlibur sekarang, jadi saya mungkin tidak bisa membaca/memeriksa semuanya dll.

Gotcha, tidak masalah. Saya akan terus memposting masalah jika saya menemukan hal-hal, dan Anda hanya membalas di waktu Anda sendiri.

Lihat sekarang :) Saya telah melakukan peningkatan dan perluasan drastis dalam beberapa hari terakhir, hanya mendorongnya (belum selesai, saat ini saya sedang memeriksa semua komponen MUI untuk memverifikasi dan meningkatkan alat peraga yang dihasilkan).

Terlihat sangat bagus, dengan dokumen yang dihasilkan juga 😍 mungkin sudah waktunya untuk memasukkan reponya sendiri?

Saya ingin membuatnya sesingkat mungkin karena akan sering digunakan, tetapi saya terbuka untuk nama lain. Meskipun saya memiliki setengah pikiran untuk hanya memiliki daftar IStyleAttribute yang berlebihan. Ini akan menghilangkan sedikit noise yang berpotensi, dan saya ragu itu akan sangat berbahaya meskipun secara teknis dapat digunakan secara tidak benar.

Itu akan berhasil juga, perpustakaan Fable menipu sistem tipe sepanjang waktu;)

Terima kasih, saya telah mengajukan masalah sekarang: dotnet/fsharp#7423

Luar biasa! Terima kasih banyak

Terlihat sangat bagus, dengan dokumen yang dihasilkan juga 😍 mungkin sudah waktunya untuk memasukkan reponya sendiri?

Saya sudah memikirkannya, tetapi masih ada beberapa bug penting (mis. #27) Saya lebih suka mencari tahu dengan kenyamanan memiliki semuanya di tempat yang sama, jadi saya pikir saya akan menyimpannya di sana sampai siap untuk prarilis di nuget (semoga tidak terlalu lama).

@Zaid-Ajaj Saya baru saja selesai dengan Feliz.MaterialUI. Akan segera diterbitkan ke repo terpisah. Akan sangat bagus jika Anda meninjaunya, pertama dan terutama untuk memeriksa beberapa keputusan desain dan memastikan konsistensi dengan Feliz, tetapi juga untuk memeriksa beberapa hal implementasi (misalnya, apakah saya menggunakan hal-hal yang akan Anda buat internal, atau adakah hal-hal yang saya 'm tidak menggunakan dari Feliz tetapi harus menggunakan).

Saat saya membuat repo baru, bolehkah saya membuat masalah yang menjelaskan apa yang ingin saya ulas, dan menandai Anda?

Saya sekarang telah mengunggah draf Feliz.MaterialUI ke cmeeren/Feliz.MaterialUI . Saya telah membuat beberapa masalah dengan hal-hal yang ingin saya tinjau.

Saya akan sangat berterima kasih jika Anda dapat meluangkan waktu untuk melihatnya!

Tidak perlu menghabiskan banyak waktu untuk setiap masalah; Saya benar-benar hanya ingin pendapat kedua untuk alasan yang disebutkan dalam komentar saya sebelumnya. Saya senang pergi ke rumput liar jika Anda mau, tetapi bahkan "ini terlihat baik-baik saja" akan bagus.

Tidak ada terburu-buru, tentu saja. :)

Kerja luar biasa @cmeeren! Sepintas, ikatannya terlihat sangat bersih, saya akan melihat setiap masalah dalam beberapa hari ke depan, saya berjanji :senyum:

Hai! Adakah kesempatan untuk terus melihat masalah? Sekali lagi jangan terburu-buru, hanya pengingat ramah karena saya belum mendengar kabar dari Anda selama beberapa minggu

Saya sebenarnya telah melihat masalahnya tetapi seperti yang saya katakan sebelumnya, apakah API bagus atau tidak berasal dari kasus penggunaan, itu sebabnya saya meminta Anda untuk menerbitkan versi alfa sehingga saya bisa mencobanya tetapi saya belum memilikinya. waktu melakukannya belum (sudah ada di benak saya minggu ini: senyum :)

Halo @cmeeren , saya kira kita dapat menganggap ini diselesaikan, bukan? Saya akan menutup masalah ini, silakan buka kembali untuk diskusi lebih lanjut jika diperlukan