Feliz: 타사 가이드

이것은 환상적인 IMHO처럼 보입니다.

감사합니다! 마음에 드신다니 다행입니다 :스마일:

Material-UI와 같은 타사 항목에 대해 확장이 간단합니까?

당연하지만, 우리는 차별적인 공용체를 사용하지 않기 때문에 접근 방식이 약간 다릅니다. 나는 시간이 허락할 때 무언가를 쓰려고 노력하지만 기본적으로 두 가지 옵션이 있다는 아이디어입니다.

• 1) 더 많은 기능으로 prop 정적 유형 확장
• 2) Mui에 필요한 모든 속성이 있는 라이브러리( Mui 일 수 있음)에 고유한 유사한 prop 정적 유형을 만듭니다. Mui $로 prop 별칭을 지정하고 Mui 관련(오버로드된) 속성 및 기능으로 Mui 를 확장할 수도 있습니다.

확장은 다음과 같이 간단합니다.

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

이것이 라이브러리의 "최종 형태"인지 그리고 그것을 확장하는 방법은 먼저 타사 라이브러리를 구축하여 그것을 시도하고 어떻게 진행되는지 보고 싶기 때문에 여전히 고려 중입니다.

감사 해요! 작동 방식을 확인하기 위해 API의 일부에 대해서만 MUI에 대한 테스트를 이미 진행 중입니다. 아마 주중/말에 공유할 예정입니다. 제가 제대로 진행하고 있고 Feliz 정신을 따르고 있는지 보기 위해 한 번만 봐주시면 정말 좋을 것 같습니다. 여기까지는 성공한 것 같습니다!

그러나 기존 prop 유형을 확장하지 않았습니다. 다른 네임스페이스( Feliz.MaterialUI )에 별도의 prop 유형을 정의했습니다. 겉보기에 훌륭하게 작동합니다. 물론 Feliz 및 Feliz.MaterialUI 를 모두 열면 일치하는 모든 유형의 모든 구성원에 액세스할 수 있습니다.

Html 에 해당하고 실제 구성 요소를 포함하는 Mui 유형이 있습니다.

(현재 #13에서 언급한 것처럼 prop 의 별도 하위 모듈에 구성 요소별 소품을 배치했습니다.)

Feliz에서 가능한 개선점은 string 가 아니라 ReactElementType $를 허용하는 reactElement 및 createElement 를 갖는 것입니다(제 생각에는). createElement (importDefault "@material-ui/core/Button") 를 호출할 수 있도록 현재 이 두 도우미를 직접 만들었습니다.

그건 그렇고, 모든 멤버가 inline 이어야 합니까? 장단점은 무엇입니까? 위에서 inline 를 사용하지 않았지만 Feliz의 모든 것은 inline 입니다.

감사 해요! 작동 방식을 확인하기 위해 API의 일부에 대해서만 MUI에 대한 테스트를 이미 진행 중입니다. 아마 주중/말에 공유할 예정입니다. 제가 제대로 진행하고 있고 Feliz 정신을 따르고 있는지 보기 위해 한 번만 봐주시면 정말 좋을 것 같습니다. 여기까지는 성공한 것 같습니다!

굉장해! 나는 당신이 그것을보고 확실히 기쁠 것입니다

그러나 기존 prop 유형을 확장하지 않았습니다. 다른 네임스페이스(Feliz.MaterialUI)에 별도의 소품 유형을 정의했습니다. 겉보기에 훌륭하게 작동합니다. 물론 Feliz와 Feliz.MaterialUI를 모두 열면 일치하는 모든 유형의 모든 구성원에 액세스할 수 있습니다.

Html에 해당하고 실제 구성 요소를 포함하는 Mui 유형이 있습니다.

그것이 내가 Mui를 위해 할 일입니다.

(현재 #13에서 언급한 것처럼 prop의 별도 하위 모듈에 구성 요소별 props를 배치했습니다.)

선택할 수 있는 옵션이 많기 때문에 Mui에 적합합니다.

Feliz에서 가능한 개선점은 문자열이 아닌 ReactElementType(내 생각에는)을 허용하는 reactElement 및 createElement를 갖는 것입니다. createElement(importDefault "@material-ui/core/Button")를 호출할 수 있도록 합니다. 현재 이 두 도우미를 직접 만들었습니다.

Interop 모듈에서 사용 중인 멤버를 검토 중입니다. 라이브러리에서 사용하던 모든 것을 공개했습니다. 안정적인 릴리스를 위해 재검토될 것입니다.

그건 그렇고, 모든 구성원이 인라인이어야합니까? 장단점은 무엇입니까? 위에서 인라인을 사용하지 않았다는 것을 알지만 Feliz의 모든 것이 인라인입니다.

위의 확장 멤버를 인라인했어야 했습니다!

경험에 따르면 속성 값이 string/int/bool/enum과 같은 원시적이면 속성을 인라인하지만 속성이 입력을 기반으로 값을 계산하는 경우 인라인하지 않는 것이 좋습니다. 인라인 함수를 호출하면 전체 함수 본문이 호출 위치에 인라인되므로 사용자가 응용 프로그램 전체에서 동일한 함수를 10번 사용하면 함수 본문은 한 번 정의되고 10번 참조되는 대신 10번 인라인으로 컴파일됩니다.

경험에 따르면 속성 값이 string/int/bool/enum과 같은 원시적이면 속성을 인라인하지만 속성이 입력을 기반으로 값을 계산하는 경우 인라인하지 않는 것이 좋습니다. 인라인 함수를 호출하면 전체 함수 본문이 호출 위치에 인라인되므로 사용자가 응용 프로그램 전체에서 동일한 함수를 10번 사용하면 함수 본문은 한 번 정의되고 10번 참조되는 대신 10번 인라인으로 컴파일됩니다.

반가워요! 그러나 (Fable의 맥락에서) 왜 처음에는 인라인입니까? "단순한" 함수/메서드 본문의 이점은 무엇입니까?

• 번들 크기: 이러한 함수가 사용되지 않는 경우(그리고 그 중 100개가 있음) 어쨌든 여전히 컴파일되어 번들 크기 AFAIK를 부풀립니다(영향은 물론 여전히 애플리케이션의 총 크기에 상대적임).
• 일반 유형 인수: Feliz와 관련이 없지만 Fable의 컨텍스트에서 호출 위치가 인라인되지 않은 경우 일반 유형 인수가 있는 일반 함수는 컴파일되지 않습니다(모든 일반 유형 인수는 컴파일 타임에 정적으로 해결되어야 함). 특별한 경우 제외 여기서 [<Inject>] ITypeResolver<'t> 를 정적 클래스의 선택적 인수로 사용할 수 있습니다(고도로 전문화된 라이브러리만 이 기능을 사용합니다. Fable.SimpleJson/Thoth.Json 참조).

프로덕션 번들을 만들 때 babel이 tree-shaking을 하고 사용하지 않는 기능을 제거한다고 생각합니다. 인라이닝은 그것을 물리칠 것입니다.

@Luiz-Monad 그렇다면 이상적으로 Feliz의 어떤 것도 인라인되어서는 안된다는 말씀이신가요? 번들 크기를 위한 인라인은 비생산적입니까?

@Luiz-Monad 당신이 말하는 것은 굉장할 것입니다! 적어도 컴파일이 그런 식으로 작동했다면. 다음은 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

여기서 prop 에는 다음이 포함됩니다.

• f() 에는 함수 본문이 포함되어 있습니다. -> 인라인되지 않고 사용되지도 않습니다.
• k() 에 함수 본문이 포함됨 -> 인라인되었지만 사용되지 않음
• g() 에는 함수가 포함되어 있습니다. -> 인라인되지 않고 사용됨

f() 및 g() 둘 다 컴파일되지 않는다고 생각할 수 있지만 그렇지 않습니다. f() (인라인되지 않고 사용되지 않음)는 어쨌든 컴파일되지만 k() (인라인됨, 사용되지 않음)는 컴파일된 번들로 만들지 않습니다.

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);

실제로 작동하지만 이를 수행하려면 webpack 를 구성해야 합니다. 트리를 흔드는 것은 우화 자체가 아니기 때문에 REPL에서 작동하지 않기 때문입니다.

전에

/// 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

후에

  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
  })

또한 테스트에 주의해야 할 사항이 있습니다. 항목 파일은 기능이 제거되지 않는다는 점에서 일종의 특별합니다. ( 정적 클래스의 초기화와 관련이 있다고 생각합니다. 모듈에 부작용을 일으키기 위해 정적 이니셜라이저 생성자를 호출해야 합니다.)

이 테스트를 위해 만든 이 저장소를 참조하십시오. https://github.com/Luiz-Monad/test-tree-shaking

예제 리포지토리에 감사드립니다! 인라인이 Feliz의 컨텍스트에서 실제로 유용한 작업을 수행하는지 확인하기 위해 이를 추가로 조사할 것입니다.

인라인이 Feliz의 컨텍스트에서 실제로 유용한 작업을 수행하는지 확인하기 위해 이를 추가로 조사할 것입니다.

멋진, 당신이 무엇을 찾을 수 있기를 기대합니다 :)

굉장해! 나는 당신이 그것을보고 확실히 기쁠 것입니다

cmeeren/fable-elmish-electron-material-ui-demo 에서 feliz 분기를 확인하십시오.

대부분의 코드는 (HTML) API 문서를 기반으로 자동 생성됩니다. 생성기 프로젝트(추악하고 해커지만 작업은 완료됨)와 실제 바인딩을 위한 프로젝트가 있습니다. 렌더러 프로젝트에서 App.fs 새로운 Feliz 스타일 바인딩을 사용하도록 변환되었습니다.

기분이 좋을 때 보시고 궁금한 점이나 생각이 있으시면 알려주세요.

@cmeeren 현재 API IMHO보다 매우 훌륭하고 훨씬 좋아 보이지만 여전히 읽기가 조금 어렵지만 라이브러리 자체의 특성에 더 가깝습니다. 친숙해야 하는 매우 구체적인 부분이 많이 있습니다. 개선할 수 있는 부분이 있다고 생각합니다. 이 예를 들면 다음과 같습니다.

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)
        ]
      ]
    ]
  ]
]

이 스니펫의 개인적인 완벽한 버전은 다음과 같이 변환하는 것입니다.

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)
        ]
      ]
    ]
  ]
]

이렇게 하면 Mui 요소를 쉽게 찾을 수 있습니다. Mui를 "점으로 표시"할 수 있고 요소를 찾으면( appBar ) 모듈 이름( AppBar )을 "점으로 표시"할 수 있기 때문입니다. 속성 등을 정의하기 위해

AppBar 도 소문자로 유지하십시오.

아이디어는 알겠지만 더 정확하게 말하면 이 API의 일반 구문은 다음과 같습니다. 여기서 {Element} 는 반응 요소입니다.

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

이에 대해 어떻게 생각하세요? 이 API는 또한 구체적인 구현을 보고 싶다면 라이브러리에 멋진 단순 요소 아이디어에 영감을 주었습니다.

나는 그것이 완벽하다고 생각하고 당신의 의견을 듣고 싶었던 것입니다. 기본 라이브러리가 작동하는 방식이기 때문에 처음에는 모든 것을 prop 아래에 두기로 선택했지만 물론 실제로 구성 요소별 소품이 없는 반면 MUI에는 구성 요소별 소품이 더 많습니다.

소문자 모듈 이름을 고수하는 것이 가장 좋을 것 같지만(추가 키 입력을 절약할 수 있음) 반론에 대해 열려 있습니다.

이 항목을 자동 생성하여 쉽게 변경할 수 있어 좋습니다.

업데이트하여 알려드립니다.

특히 한 가지 의견을 듣고 싶습니다. ClassName 물건입니다. makeStyles 후크는 전달된 것과 동일한 props를 가진 객체를 반환하지만 모든 (JSS) 요소는 사용할 클래스 이름인 문자열로 대체되었습니다(예: prop.className ).

이제 F#에 입력할 방법이 없으므로 가지고 있는 것으로 작업해야 합니다. 일반적으로 스타일 개체의 모든 소품은 IStyleAttribute list 입니다. 이것은 IStyleAttribute list prop.className 에 대한 오버로드를 추가할 수 있음을 의미합니다. 물론 런타임에 문자열이기 때문에 거짓말입니다. 실제로 IStyleAttribute list 를 전달하면 실패합니다. prop.className 외에도 이것은 모든 classes.<element>.<classesName> ( <element>.classes [ ... ] 에서 사용됨)에도 적용됩니다. 클래스 이름(문자열)도 허용합니다.

보시다시피 내가 한 일은 스타일 개체의 모든 IStyleAttribute list 속성을 asClassName 로 "요구"하는 것입니다 IClassName (원하는 경우 string 에 대한 프록시). 그런 다음 IClassName prop.className 에 오버로드를 추가하고 모든 classes 소품이 IClassName 수락하도록 했습니다. 나는 그것이 더 강력하게 타이핑되는 것을 좋아하지만 추가 타이핑이 필요하다는 것은 좋아하지 않습니다(모든 최상위 CSS 규칙에 대해 asClassName ). 컴파일러는 당신이 그것을 놓치면 불평할 것이지만, 그것은 당신에게 무엇을 해야 하는지 말하지 않을 것이고 여전히 여분의 잡음입니다.

이에 대한 의견이 있습니까?

또한, 나는 이것을 알아차렸습니다:

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

여기에서 이중 괄호가 필요합니다. 그렇지 않으면 F#이 $# 대신 Home 로 설정된 (존재하지 않는) page 매개변수를 사용하여 $ listItem.divider 를 호출하려고 하는 것으로 해석하기 때문입니다 value 매개변수가 page = Home 로 설정됨). 그것을 피하는 방법이 보이십니까?

안녕하세요 @cmeeren 우선, 저는 이 구문을 정말 좋아합니다.

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)
        ]
      ]
    ]
  ]
]

보기만해도 너무 깔끔하고 심플해요! 내가 당신이었다면 prop.className 대신에(또는 함께) prop.className appBar.className 와 같은 구성 요소별 소품에 일반 prop 기능 중 일부를 복제했을 것이므로 그것들은 모두 대칭적으로 보이지만 더 중요한 것은 makeStyles 도 Mui 전용이기 때문에 문자열을 사용하는 일반 prop.className 대신 Mui 전용 구성요소에 IClassName 오버로드를 제공하는 것입니다. 구성 요소이며 Mui 구성 요소에만 적용됩니다.

makeStyles 가능한 최선의 방법을 선택했다고 생각합니다. 적어도 지금 당장은 더 나은 방법이 생각나지 않습니다( asClassName , 아마도 Styles.createClass 의 열렬한 팬은 아니지만

listItem.divider ((page = Home)) 에 관해서는 까다롭습니다. 더미 함수 let when (x: bool) = x 를 추가할 수 있지만 그것은 단지 노이즈입니다. F# 컴파일러가 함수의 적절한 오버로드를 해결할 수 없는 이유를 생각할 수 없기 때문에 컴파일러 버그로 신고하는 것이 가장 좋다고 생각합니다. 직접 시도하지는 않았지만 시간이 되면 살펴보겠습니다.

마지막으로 저는 이번 주에 평소처럼 응답하지 않습니다. 지금 휴가 중이기 때문에 모든 것을 읽거나 확인하지 못할 수도 있습니다.

내가 당신이었다면 아마도 prop.className 대신에(또는 함께) prop.className appBar.className 와 같은 구성 요소별 소품으로 일반 prop 기능 중 일부를 복제했을 것이므로 그것들은 모두 대칭적으로 보이지만 더 중요한 것은 makeStyles 도 Mui 전용이기 때문에 문자열을 사용하는 일반 prop.className 대신 Mui 전용 구성요소에 IClassName 오버로드를 제공하는 것입니다. 구성 요소이며 Mui 구성 요소에만 적용됩니다.

지금 확인해보세요 :) 지난 몇 일간 과감한 개선과 확장을 했고 그냥 밀어넣었습니다(완료되지 않았습니다. 현재 생성된 props를 확인하고 개선하기 위해 모든 MUI 구성 요소를 살펴보고 있습니다).

makeStyles 가능한 최선의 방법을 선택했다고 생각합니다. 적어도 지금 당장은 더 나은 방법이 생각나지 않습니다( asClassName , 아마도 Styles.createClass 의 열렬한 팬은 아니지만 대신

많이 쓰이게 될 것 같아서 최대한 짧게 하고 싶지만, 다른 이름도 가능합니다. 나는 단지 IStyleAttribute list 과부하를 가질 생각이 절반이 있지만. 잠재적으로 상당한 소음을 제거할 수 있으며, 기술적으로 잘못 사용할 수 있더라도 매우 위험할 것이라고 생각합니다.

listItem.divider ((page = Home)) 에 관해서는 까다롭습니다. 더미 함수 let when (x: bool) = x 를 추가할 수 있지만 그것은 단지 노이즈입니다. F# 컴파일러가 함수의 적절한 오버로드를 해결할 수 없는 이유를 생각할 수 없기 때문에 컴파일러 버그로 신고하는 것이 가장 좋다고 생각합니다. 직접 시도하지는 않았지만 시간이 되면 살펴보겠습니다.

감사합니다. 지금 문제를 제출했습니다: https://github.com/dotnet/fsharp/issues/7423

마지막으로 저는 이번 주에 평소처럼 응답하지 않습니다. 지금 휴가 중이기 때문에 모든 것을 읽거나 확인하지 못할 수도 있습니다.

문제 없습니다. 나는 문제를 발견하면 계속해서 문제를 게시할 것이고 당신은 당신의 시간에 답장을 보내십시오.

지금 확인해보세요 :) 지난 몇 일간 과감한 개선과 확장을 했고 그냥 밀어넣었습니다(완료되지 않았습니다. 현재 생성된 props를 확인하고 개선하기 위해 모든 MUI 구성 요소를 살펴보고 있습니다).

생성된 문서와 함께 정말 좋아 보입니다 😍 어쩌면 자체 저장소에 넣을 시간이 있습니까?

많이 쓰이게 될 것 같아서 최대한 짧게 하고 싶지만, 다른 이름도 가능합니다. IStyleAttribute 목록 오버로드를 갖고 싶다는 생각은 반쯤 가지고 있지만. 잠재적으로 상당한 소음을 제거할 수 있으며, 기술적으로 잘못 사용할 수 있더라도 매우 위험할 것이라고 생각합니다.

그것도 작동합니다. Fable 라이브러리는 항상 유형 시스템을 속입니다 ;)

감사합니다. 지금 문제를 제출했습니다: dotnet/fsharp#7423

엄청난! 정말 감사합니다

생성된 문서와 함께 정말 좋아 보입니다 😍 어쩌면 자체 저장소에 넣을 시간이 있습니까?

나는 그것에 대해 생각하고 있지만 여전히 몇 가지 중요한 버그가 있습니다(예: #27). 모든 것을 같은 장소에 두는 편리함으로 파악하는 것이 더 좋을 것이므로 준비될 때까지 거기에 보관할 것입니다. nuget의 프리릴리즈용(너무 길지 않기를 바랍니다).

@Zaid-Ajaj Feliz.MaterialUI 작업이 거의 끝났습니다. 곧 별도의 리포지토리에 게시할 예정입니다. 먼저 검토하여 일부 디자인 결정을 확인하고 Feliz와의 일관성을 확인하고 일부 구현 항목(예: 내부에서 만들 항목을 사용하고 있는지, 아니면 Feliz에서 사용하지 않지만 사용해야 함).

새 리포지토리를 만들 때 검토하고 싶은 내용을 설명하는 문제를 만들고 태그를 지정해도 괜찮습니까?

이제 Feliz.MaterialUI 초안을 cmeeren/Feliz.MaterialUI 에 업로드했습니다. 검토하고 싶은 사항에 대해 몇 가지 문제를 만들었습니다.

시간을 내서 봐주시면 정말 감사하겠습니다!

각 문제에 많은 시간을 할애할 필요가 없습니다. 이전 의견에서 언급한 이유로 두 번째 의견을 원합니다. 원한다면 잡초 속으로 들어가도 좋겠지만 "이건 괜찮아 보인다"는 것만으로도 좋겠어.

물론 서두르지는 않습니다. :)

멋진 작품 @cmeeren! 언뜻보기에 바인딩은 매우 깨끗해 보입니다. 앞으로 며칠 동안 각 문제를 살펴보겠습니다. 약속합니다.스마일:

이봐! 문제를 계속 볼 기회가 있습니까? 다시 한 번 서두르지 마세요. 몇 주 동안 연락이 없었기 때문에 친절한 알림입니다 😃

실제로 문제를 살펴보았지만 이전에 말했듯이 API가 좋은지 아닌지는 사용 사례에서 나오는 것이므로 시도해 볼 수 있도록 알파 버전을 게시해 달라고 요청했지만 아직 시간은 아직 입니다(이번 주 생각이 났습니다 :스마일 :)

@cmeeren님 , 이 문제가 해결된 것으로 간주할 수 있습니다. 맞습니까? 나는 문제를 닫을 것입니다, 필요한 경우 추가 토론을 위해 다시 엽니다