Feliz: Minha jornada com Feliz | Uma comparação entre Fable.React e Feliz

Ótima análise.

Para mim, pessoalmente, embora a formatação de lista dupla seja uma dor às vezes, sinto que olhando para o código Fable.React consigo ver melhor a estrutura do html subjacente. É div [.., não Html.div [.... (etc). Não é grande coisa, mas meu cérebro parece ter uma análise mais fácil de Fable.React.

Ótimo, escreva @MangelMaxime , você fez muitos pontos positivos.

Pelo que reuni, a principal conclusão disso são os problemas de como a biblioteca é estendida e os problemas que ocorrem quando não é feito de maneira ideal.

Eu posso definitivamente concordar que escrever bibliotecas para Feliz coloca muito mais trabalho no desenvolvedor, mas na minha opinião vale a pena o esforço quando a API resultante é tão boa de usar.

Escrevi um bom número de extensões para Feliz então acho que posso fornecer alguns insights sobre como mitigar muitos desses problemas:

Sobrecargas

Eu uso o Visual Studio e não tenho problemas para encontrar quais sobrecargas estão disponíveis para mim, talvez isso seja algo que possa ser melhorado no final do ionido?

Poderíamos apenas fazer prop.text ser uma única função inline que requer o membro toString e aceitar qualquer tipo?

Chamadas de retorno:

Ao invés de:

[<Erase>]
type editor =
    /// <summary>Triggered when the Editor has been mounted</summary>
    static member inline editorDidMount (f : System.Func<Monaco.Editor.IStandaloneCodeEditor, Monaco.IExports, unit>) = Interop.mkAttr "editorDidMount" f

Escrever:

[<Erase>]
type editor =
    /// <summary>Triggered when the Editor has been mounted</summary>
    static member inline editorDidMount (f : Monaco.Editor.IStandaloneCodeEditor -> Monaco.IExports -> unit) = Interop.mkAttr "editorDidMount" (Func<_,_,_> f)

Você pode então ligar para a propriedade como seria de esperar do lado do cliente.

Escrevendo código inválido

Eu não vi ninguém aplicar isso tanto quanto eu fiz em algumas de minhas bibliotecas, e pode não ser totalmente aplicável ao estender Html . A maneira de evitar isso é adicionando tipos de interface adicionais às propriedades que você define, em minha maior Feliz library Feliz.Plotly Eu a tenho configurado de forma que você obterá um erro do compilador se você tente usar uma propriedade que não seja válida. A única desvantagem é que é um pouco trabalhoso para o desenvolvedor da biblioteca.

[<AutoOpen;EditorBrowsable(EditorBrowsableState.Never)>]
module Types =
  type IPlotProperty = interface end
  type IModeBarButtonsProperty = interface end
  type IAaxisProperty = interface end
  type IAggregateProperty = interface end
  type IAggregationProperty = interface end
  type IAggregationsProperty = interface end
  type IAngularaxisProperty = interface end
  type IAnimationProperty = interface end
  type IAnnotationProperty = interface end
  type IAnnotationsProperty = interface end
  type IAreaProperty = interface end
  type IAspectratioProperty = interface end
  type IAxisProperty = interface end
  type IBarProperty = interface end
  type IBarpolarProperty = interface end
  type IBaxisProperty = interface end
  type IBorderProperty = interface end
  type IBoxProperty = interface end
  type IButtonProperty = interface end
  type ICameraProperty = interface end
  type ICandlestickProperty = interface end
  type ICapsProperty = interface end
  type ICarpetProperty = interface end
  type ICaxisProperty = interface end
  type ICellsProperty = interface end
  type ICenterProperty = interface end
  type IChoroplethProperty = interface end
  type IChoroplethmapboxProperty = interface end
  type ICircleProperty = interface end
  type IColoraxisProperty = interface end
  type IColorbarProperty = interface end
  type IColorscaleProperty = interface end
  type IColorscalesProperty = interface end
  type IConcentrationscalesProperty = interface end
  type IConeProperty = interface end
  type IConfigProperty = interface end
  type IConnectorProperty = interface end
  type IContourProperty = interface end
  type IContourcarpetProperty = interface end
  type IContoursProperty = interface end
  type ICumulativeProperty = interface end
  type ICurrentvalueProperty = interface end
  type IDecreasingProperty = interface end
  type IDeltaProperty = interface end
  type IDensitymapboxProperty = interface end
  type IDiagonalProperty = interface end
  type IDimensionProperty = interface end
  type IDimensionsProperty = interface end
  type IDomainProperty = interface end
  type IEditsProperty = interface end
  type IErrorXProperty = interface end
  type IErrorYProperty = interface end
  type IErrorZProperty = interface end
  type IEyeProperty = interface end
  type IFillProperty = interface end
  type IFilterProperty = interface end
  type IFontProperty = interface end
  type IFrameProperty = interface end
  type IFramesEntryProperty = interface end
  type IFramesProperty = interface end
  type IFunnelProperty = interface end
  type IFunnelareaProperty = interface end
  type IGaugeProperty = interface end
  type IGeoProperty = interface end
  type IGradientProperty = interface end
  type IGridProperty = interface end
  type IGroupbyProperty = interface end
  type IHeaderProperty = interface end
  type IHeatmapProperty = interface end
  type IHeatmapglProperty = interface end
  type IHistogram2dProperty = interface end
  type IHistogram2dcontourProperty = interface end
  type IHistogramProperty = interface end
  type IHoverlabelProperty = interface end
  type IImageProperty = interface end
  type IImagesProperty = interface end
  type IIncreasingProperty = interface end
  type IIndicatorProperty = interface end
  type IInsidetextfontProperty = interface end
  type IIsosurfaceProperty = interface end
  type ILabelfontProperty = interface end
  type ILataxisProperty = interface end
  type ILayerProperty = interface end
  type ILayersProperty = interface end
  type ILayoutProperty = interface end
  type ILeafProperty = interface end
  type ILegendProperty = interface end
  type ILightingProperty = interface end
  type ILightpositionProperty = interface end
  type ILineProperty = interface end
  type ILinkProperty = interface end
  type ILonaxisProperty = interface end
  type IMapboxProperty = interface end
  type IMarginProperty = interface end
  type IMarkerProperty = interface end
  type IMeanlineProperty = interface end
  type IMesh3dProperty = interface end
  type IModebarProperty = interface end
  type INodeProperty = interface end
  type INumberProperty = interface end
  type IOhlcProperty = interface end
  type IOutsidetextfontProperty = interface end
  type IPadProperty = interface end
  type IParcatsProperty = interface end
  type IParcoordsProperty = interface end
  type IPathbarProperty = interface end
  type IPieProperty = interface end
  type IPointcloudProperty = interface end
  type IPolarProperty = interface end
  type IProjectProperty = interface end
  type IProjectionProperty = interface end
  type IRadialaxisProperty = interface end
  type IRangebreakProperty = interface end
  type IRangebreaksProperty = interface end
  type IRangefontProperty = interface end
  type IRangeselectorProperty = interface end
  type IRangesliderProperty = interface end
  type IRotationProperty = interface end
  type ISankeyProperty = interface end
  type IScatter3dProperty = interface end
  type IScatterProperty = interface end
  type IScattercarpetProperty = interface end
  type IScattergeoProperty = interface end
  type IScatterglProperty = interface end
  type IScattermapboxProperty = interface end
  type IScatterpolarProperty = interface end
  type IScatterpolarglProperty = interface end
  type IScatterternaryProperty = interface end
  type ISceneProperty = interface end
  type ISelectedProperty = interface end
  type IShapeProperty = interface end
  type IShapesProperty = interface end
  type ISlicesProperty = interface end
  type ISliderProperty = interface end
  type ISlidersProperty = interface end
  type ISortProperty = interface end
  type ISpaceframeProperty = interface end
  type ISplomProperty = interface end
  type IStartsProperty = interface end
  type IStepProperty = interface end
  type IStepsProperty = interface end
  type IStreamProperty = interface end
  type IStreamtubeProperty = interface end
  type IStyleProperty = interface end
  type IStylesProperty = interface end
  type ISunburstProperty = interface end
  type ISurfaceProperty = interface end
  type ISymbolProperty = interface end
  type ITableProperty = interface end
  type ITernaryProperty = interface end
  type ITextfontProperty = interface end
  type IThresholdProperty = interface end
  type ITickfontProperty = interface end
  type ITickformatstopProperty = interface end
  type ITickformatstopsProperty = interface end
  type ITilingProperty = interface end
  type ITitleProperty = interface end
  type ITotalsProperty = interface end
  type ITracesProperty = interface end
  type ITransformsProperty = interface end
  type ITransitionProperty = interface end
  type ITreemapProperty = interface end
  type IUniformtextProperty = interface end
  type IUnselectedProperty = interface end
  type IUpProperty = interface end
  type IUpdatemenuProperty = interface end
  type IUpdatemenusProperty = interface end
  type IViolinProperty = interface end
  type IVolumeProperty = interface end
  type IWaterfallProperty = interface end
  type IXProperty = interface end
  type IXaxisProperty = interface end
  type IXbinsProperty = interface end
  type IYProperty = interface end
  type IYaxisProperty = interface end
  type IYbinsProperty = interface end
  type IZProperty = interface end
  type IZaxisProperty = interface end
  type IButtonsProperty = inherit IModeBarButtonsProperty
  type IMeasureProperty = interface end
  type ITemplateProperty = interface end

De maneira semelhante, você também pode implementar coisas no código da biblioteca para combinar as propriedades "automagicamente", se desejar. Não tenho certeza de como isso funciona ao usar coisas fora da sua própria biblioteca. O truque para isso é fazer com que esses itens sejam de um tipo diferente de apenas IReactProperty . Por exemplo, em Feliz.Plotly eu faço muitas coisas onde, dependendo das configurações fornecidas, irei modificar / coletar / alterar a entrada do usuário para traduzi-la adequadamente para o que o código real precisa se parecer. É muito bom em alguns aspectos remover coisas que estão sempre presentes.

Conclusão

Acho que grande parte da dor que você teve poderia ser resolvida com uma documentação melhor sobre como navegar escrevendo suas próprias bibliotecas do jeito "Feliz". Talvez @ Zaid-Ajaj e eu possamos trabalhar nisso no futuro.

Obrigado @ l3m

Para mim, pessoalmente, embora a formatação de lista dupla seja uma dor às vezes, sinto que olhando para o código Fable.React consigo ver melhor a estrutura do html subjacente. É div [.., não Html.div [.... (etc). Não é grande coisa, mas meu cérebro parece ter uma análise mais fácil de Fable.React.

Na verdade, mudar a forma de ler o código não é fácil e é por isso que mencionei que não devemos vê-lo como HTML no meu caso, ele me ajudou a fazer a mudança.

Suponho que com F # 5 e a capacidade de "abrir classes estáticas", Feliz será capaz de suportar as sintaxes Html.div e div dependendo se você abre ou não a classe Html.

Obrigado @Shmew pelo comentário e na verdade esqueci que existem vários tipos de "bibliotecas" para o Feliz.

Sobre a "Gravação de código inválido" sim, mas em algumas bibliotecas, queremos "estender" o tipo IReactProperty para evitar a situação Fulma em que você precisa passar propriedades padrão por meio de um auxiliar especial como Props . A razão é que os "componentes" Bulma são apenas uma especialização sobre os elementos DOM.

Eles são apenas código que injeta uma classe por padrão no elemento HTML.

Bulma.button gera <div class="button">

No caso de uma biblioteca que funciona com componentes "reais" (desculpe, não sei como nomeá-la de outra forma), sua solução é de fato a certa. Por exemplo, esta é a abordagem feita por Fable.ReactLeaflet, onde estou definindo as propriedades específicas para cada componente. E, portanto, os componentes não precisam oferecer suporte a todas as propriedades HTML padrão.

Sobre sua solução para "Callbacks" não funcionou para mim. Mas a função passada por Fable tinha argumentos curry e, a menos que eu quisesse escrever algo como myFunction(arg1)(arg2) , eu tinha que forçar a versão não urgente via System.Func .

Se você souber como fazer isso funcionar, ficarei feliz em ver um PR enviado para corrigi-lo em https://github.com/fable-compiler/repl/pull/108/files

Olá @MangelMaxime ,

Em primeiro lugar, quero agradecer por dedicar seu tempo e esforço não apenas para experimentar Feliz em um projeto, mas também por escrever uma análise tão extensa. Tenho certeza de que muitos usuários do Fable o acharão muito útil e informativo.

Eu realmente aprecio esse tipo de feedback e abertura e acredito que é crucial para tornar esta biblioteca o melhor que pode ser junto com seu ecossistema: ore:

Falarei sobre o Feliz.Bulma daqui a pouco porque acho que é meio especial no ecossistema, primeiro vou responder a alguns problemas que você tem que já podem ser consertados sem mudanças na biblioteca.

Sobrecargas de onChange

você precisa dizer qual tipo de evento deseja explicitamente.

Na verdade, você não. O tipo deve ser inferido de seu tipo de mensagem da seguinte maneira:

prop.onChange (ChangeGistToken >> dispatch)

Dependendo do tipo de ChangeGistToken , a sobrecarga correta será inferida. Quando o caso DU for ChangeGistToken of string , a sobrecarga de string -> unit será escolhida. Mas também pode ser FileSelected of File quando o tipo de entrada é file , caso em que a sobrecarga File -> unit será inferida e assim por diante. Você não precisa do açúcar sintático de ev.Value de Fable.React

prop.onCheckedChange será removido porque onChange lida com o caso booleano

Retornos de chamada com vários argumentos

@Shmew já tocou no assunto e, de fato, essa é a maneira de resolver esses tipos de propriedades. É fundamental entender que, ao implementar extensões Feliz, você pode fazer transformações antes de definir a propriedade:

type myExtension = 
    static member inline extenstionProperty value = 
        // transform value here
        let transformedValue = doWeirdStuffWith value
        Interop.mkAttr "extenstionProperty" transformedValue

Seguindo esta lógica, você pode converter 'A -> 'B -> unit em Func<'A, 'B, unit> internamente:

[<Erase>]
type editor =
    /// <summary>Triggered when the Editor has been mounted</summary>
    static member inline editorDidMount (f : Monaco.Editor.IStandaloneCodeEditor -> Monaco.IExports -> unit) = 
        let transformedFunction = System.Func<Monaco.Editor.IStandaloneCodeEditor, Monaco.IExports, unit>(fun editor exported -> f editor exported)
        Interop.mkAttr "editorDidMount" transformedFunction

Esta é uma versão mais explícita do que a fornecida por @Shmew (como você sabe com ligações, você sempre tem que brincar um pouco com elas para acertar). Um exemplo prático disso está aqui

Segurança de tipo no ecossistema Feliz

Como @Shmew mencionou acima: uma extensão Feliz adequada não permite que você escreva código que se comporte incorretamente e restringir os tipos de propriedades permite que você implemente isso. Você pode construir propriedades que retornam IReactProperty como Feliz.Recharts, que permite a compatibilidade com as propriedades existentes em prop ou pode implementar um tipo mais especializado ISpecialiedProperty para oferecer suporte apenas um subconjunto das propriedades enquanto duplica os nomes de algumas propriedades de IReactProperty para garantir a compatibilidade com versões anteriores:

type felizExtension = 
    static member inline specializedProp (value: string) : ISpecializedProperty = unbox (prop.text value) 

É o que venho fazendo com Feliz.AntDesign, por exemplo aqui onde estou duplicando algumas propriedades para disponibilizar a partir do ponto de entrada button (Posteriormente, poderia tornar as propriedades mais especializadas com tipos restritos, mas no início , backward-compat é onde você começa). Eu acredito que Feliz.MaterialUI faz coisas semelhantes para estender IReactProperty ao invés de propriedades especializadas. Isso traz o caso de Feliz.Bulma.

O caso de Feliz.Bulma

Antes de Feliz.Bulma ser implementado, eu tinha em mente que não há necessidade de construir extensões Feliz para frameworks somente CSS. Feliz já torna muito fácil compor vários nomes de classes e trabalhar com eles condicionalmente. Agora, com yield implícito em F # é ainda mais fácil. Combine isso com TypedCssClasses e você removerá a necessidade de implementar qualquer estrutura somente CSS. Custos zero de implementação e manutenção. Basta usar a folha de estilo digitada e usar a documentação já muito boa do próprio projeto, em vez de ter que construir você mesmo um site de documentação.

No entanto, depois de ver a implementação do Feliz.Bulma por @Dzoukr , fez sentido: você poderia simplificar muito o código introduzindo "pontos de entrada" específicos para os componentes CSS de um módulo do Bulma para obter Bulma.button , Bulma.card etc. Estes são realmente agradáveis ​​de usar. Quanto aos modificadores, acho que a abordagem de Roman é fácil de seguir e trabalhar, mas, como você disse, às vezes pode dar resultados interessantes. Certamente, há mais a melhorar nesse departamento e, em qualquer caso, acho que Roman fez um ótimo trabalho ao seguir a visão de Feliz para construir algo fácil de aprender e usar.

Gestão de embalagens de Feliz

Eu só quero apontar uma grande diferença nos atuais Fable.React e Feliz : o controle de versão e gerenciamento de pacotes. As versões do Feliz são todas as suas bibliotecas do ecossistema são compatíveis com Femto, o que elimina o fardo dos usuários de ter que instalar manualmente os pacotes npm necessários ou saber com qual versão eles são compatíveis. Isso é diferente de muitas, senão todas as bibliotecas Fable.React derivadas e até mesmo Fable.React si, onde esse não é o caso.

Planos futuros

• Escrever (ainda mais) documentação sobre como construir extensões estilo Feliz e o que deve aderir.
• Construindo um analisador de Feliz para o próprio Feliz, mas possivelmente para seu ecossistema

Na verdade, você não. O tipo deve ser inferido de seu tipo de mensagem da seguinte maneira:

prop.onChange (ChangeGistToken >> dispatch)

Na verdade, não pensei sobre esse uso.

Retornos de chamada com vários argumentos

@Shmew já tocou no assunto e, de fato, essa é a maneira de resolver esses tipos de propriedades.

Desculpe, não vi o final do snippet fornecido por @Shmew. Acabei de ver a declaração de assinatura e pensei que não, não funciona.

Vocês estão certos, podemos fazer a transformação antes de passar o valor para o imóvel.

O caso de Feliz.Bulma

Sim, TypedCssClasses está ok, mas em comparação com Fulma ou Feliz.Bulma, não pode fornecer o mesmo nível de recursos. Porque nem tudo está contido no arquivo CSS.

Outra coisa é que no modo dev, nem sempre temos o arquivo gerado no disco e não tenho certeza se TypedCssClasses suporta este cenário.

Acho que Roman fez um ótimo trabalho ao seguir a visão de Feliz para construir algo fácil de aprender e usar.

Eu concordo, só acho que precisamos adicionar um pouco do trabalho feito na Fulma para torná-lo semelhante. Como eu disse, precisamos encontrar o meio-termo correto entre os dois.

Os recursos ausentes que tenho em mente agora permitem controlar o elemento de saída e tornar mais fácil estender o conjunto de cores com suporte. Não acho que isso vá adicionar muita complexidade.

@ Zaid-Ajaj, obrigado pelo feedback e especialmente por me indicar a direção certa sobre como usar o potencial do Feliz.
Admito que realmente não li a documentação do Feliz (isso é ruim, eu sei), então talvez eles estejam documentados nela. Se não, acho que sabemos mais algumas coisas a serem adicionadas :)

Obrigado @MangelMaxime - essa é uma ótima comparação. Você não mencionou o Fantomas em nenhum lugar para a formatação automática do código - você teve a chance de trabalhar com o Fantomas com o Fable.React ou o Feliz?
Em um dos meus projetos Fable onde uso o Fantomas, ativei a formatação automática ao salvar o arquivo em Ionide e devo dizer que é realmente um impulsionador da produtividade - não há necessidade de se preocupar com a formatação manual!
Eu realmente acho que Fantomas está ganhando impulso agora e adoraria ver sua adoção mais ampla, também em conjunto com Fable e React / Feliz.

@theimowski Não utilizo o Fantomas há tempos.

Principalmente porque estava bagunçando meu código e tornando-o muito difícil de ler. Pela minha experiência até não estava jogando bem com Fable.React e Feliz.

Também não gosto do padrão do Fantomas, preciso verificá-lo novamente no futuro, quando souber como desejo que meu código seja indentado. Mas, pelo que eu olhei para o repo, não acho que ele vai atender às minhas necessidades principalmente por causa do Fantomas formatar o código dependendo do tamanho do contexto.

Por exemplo, se eu escrever algo assim:

type Test =
    {
        Prop1 : string
    }

Eu quero que continue assim e não se torne type Test = { Prop1 : string } só porque pode caber em uma única linha.

Talvez um disco não seja um bom exemplo, mas espero que você entenda o que quero dizer :)

@theimowski que ótimo ouvir, eu uso fantomas em meus projetos não-Fable. Vou ter que tentar novamente e ver como funciona.

@MangelMaxime obrigado pelo seu trabalho. De alguma forma, seu projeto Fulma me atacou para o mundo das fábulas. E eu realmente gosto da viagem.

Eu também gosto da lista única, mas também gosto de DU do que substituições de membros de classes. Às vezes me pergunto se o DU suporta override, então seria ótimo.
Porque eu já uso muito o Fable.React, mas ainda quero uma lista única, então criei um operador> e posso usá-lo assim:

let myView =
    div </> [
        Classes [ ""; ""; "" ]
        Children [
              ...
        ]
    ]

O operador é bastante simples e também tira proveito do DU, você pode verificar minha implementação aproximada aqui: https://github.com/albertwoo/Fun.LightForm/blob/master/src/Fun.LightForm.Fable/Fable.React. Extra.fs

@ Zaid-Ajaj Obrigado também pelo seu excelente trabalho, também comecei a converter alguns dos meus projetos para Feliz e Feliz.Material.

Obrigado!

Olá @MangelMaxime ,
Em primeiro lugar, obrigado! Francamente, eu não esperava que alguém desse uma olhada tão profunda na biblioteca que criei principalmente para dogfooding em projetos próprios e publiquei como efeito colateral. Engraçado como o pensamento inicial de "ei, como @ Zaid-Ajaj projetou Feliz é ótimo - vamos fazer o mesmo com Bulma" inchou.

Já criei um novo problema no Feliz.Bulma repo e adoro discutir como tornar a v2 ainda melhor. Parece que concordamos na maioria das questões, então não deve ser problema iniciar version2 branch. Analisar também quais são os planos de Zaid para o próximo lançamento importante pode ser útil para manter a API entre as versões principais mais recentes 100% compatível.

De qualquer forma, obrigado novamente - ótima análise!

Correndo o risco está reabrindo velhas discussões (! Sorry) Eu só queria acrescentar meus dois centavos sobre o debate recuo - este é (mais ou menos) o estilo seguimos que não permitem bom, identation consistente e seguir para o Fable.React estilo.

O único lugar ao qual isso não se aplica, no entanto, é para estilos não triviais. No entanto, em nossa experiência, isso representa apenas uma minoria de elementos (talvez 10-20%).

div [ ] [
    Hero.hero [ Hero.IsFullHeight ] [
        Hero.body [ ] [
            Container.container [ ] [
                img [ Src "img/fable-ionide.png"
                      Style [ Display DisplayOptions.Block
                              Width "auto"
                              Margin "auto" ]
                    ]
                br [ ]
                Heading.h3 [ Heading.Modifiers [ Modifier.TextAlignment (Screen.All, TextAlignment.Centered) ] ] [
                    str "Fable REPL"
                ]
                Heading.p [ Heading.IsSubtitle
                            Heading.Is5
                            Heading.Modifiers [ Modifier.TextAlignment (Screen.All, TextAlignment.Centered) ] ] [
                    str "is only available on desktop"
                ]
            ]
        ]
    ]
]

Além disso, se você usar o VS Code e algo como os colchetes do arco-íris, pode realmente ajudar a evitar a sobrecarga dos colchetes.

Outra coisa a considerar (talvez eu não tenha percebido isso acima) é que o GiraffeViewEngine usa o estilo Fable.React, ou seja, o elemento attr-list child-list, então apenas algo para pensar em termos de pessoas em transição entre os dois.

@ Zaid-Ajaj faz uma boa observação sobre Femto; há alguma razão pela qual isso não poderia ser implementado por componentes do estilo Fable.React, ou há algo inerente ao estilo Feliz ao qual o Femto está acoplado?

há alguma razão pela qual isso não poderia ser implementado por componentes do estilo Fable.React, ou há algo inerente ao estilo Feliz ao qual o Femto está acoplado?

@isaacabraham

Bibliotecas derivadas de Fable.React podem (e devem) adicionar metadados Femto, mas o próprio Fable.React não pode, porque tem uma combinação incompatível de react , react-dom e react-native . @MangelMaxime iniciou algum trabalho na divisão de pacotes, mas foi muito mais trabalhoso do que o esperado e provavelmente apresentará alterações importantes.

O que isso significa para bibliotecas derivadas de Fable.React é que elas devem incluir não apenas metadados npm de suas dependências, mas também versões compatíveis de react e react-dom porque Fable.React não não faça isso para eles (ao contrário de Feliz, que começa com react e react-dom modo que as extensões de Feliz adicionam apenas o que precisam). Infelizmente, ainda não vi nenhuma dessas bibliotecas tomar a iniciativa de melhorar a situação, mesmo que a solução já exista há algum tempo.

Com relação à formatação: Fantomas ainda não é capaz de formatar DSLs de uma maneira sensata e requer algum trabalho para fazer a formatação da lista configurável ou tem algum tipo de sinalizador "Feliz-mode" para formatar o React DSL usando bons padrões (que temos que vir com)

@ Zaid-Ajaj O problema com as dependências npm do React também é mais complexo, pois deve ser possível usar o preact em vez do react, sem quebrar o Femto.

@ l3m Sim, mas neste caso poderíamos fazer um acréscimo ao Femto para apoiar este caso. Ele me lembra de algo, então talvez tenhamos um problema sobre isso no repositório Femto (desculpe, não tenho tempo para verificar agora ^^)

@ l3m Preact pode ser usado no lugar do React, independentemente dos metadados Femto npm, porque você só precisa configurar aliases de importação de módulo de acordo com as diretrizes em Alternando para Preact quando tiver um aplicativo React existente.

Construir uma associação Preact pura (código 100% não React) não é o objetivo de Feliz e provavelmente deve ser implementada como uma biblioteca autônoma (Feliz.Preact que não depende de Feliz) a partir da qual associações somente Preact serão estendidas e usado no caso de você querer ficar longe de preact/compat

@ Zaid-Ajaj Estou usando o preact agora no meu aplicativo em Elmish e ele funciona bem. Eu estava apenas desconfiado sobre o Femto modificar packages.json se ele ver um nuget com React deps e eu queria destacar isso. Se isso não for um problema, tanto melhor.

Além disso, preact/compat não é mais necessário com o pré-ato mais recente, agora está no núcleo.

Correndo o risco de reabrir discussões antigas (desculpe!). Eu só queria adicionar meus dois centavos ao debate sobre recuo - este é (mais ou menos) o estilo que seguimos, que _faz_ permite uma identificação consistente e agradável para o Fable.React estilo.

Estou recuando o código de uma maneira muito semelhante ao de Isaac, e é bastante legível.
Eu sei que é difícil comparar com uma única forma de lista de fazer as coisas, mas o recuo da postagem original pode refletir algo semelhante ao seu código para comparar melhor.

Suponho que com F # 5 e a capacidade de "abrir classes estáticas", Feliz será capaz de suportar as sintaxes Html.div e div dependendo se você abre ou não a classe Html.

Isso seria muito legal. Seria possível tornar a classe Html estática para que ela pudesse ser aberta?

@ fc1943s Html , prop e style são classes estáticas. No entanto, não recomendo abri-los quando o recurso se tornar disponível no F # 5, porque o objetivo principal é ter um agrupamento e um ponto de entrada de descoberta para as funções disponíveis dentro dessa classe estática.

Como abrir a classe estática atrapalharia a descoberta? Você ainda pode digitar Feliz.Html.

@MaxWilsonMS Isso exigiu etapas adicionais para

E você escreveria Feliz.Html.div e então apagaria Feliz.Html. parte que parece estranha.

O que é bom é que as pessoas podem optar por abrir a classe estática ou não dependendo de suas preferências. :)

Não tenho certeza de como isso será útil, já que estou repetindo o que foi dito acima, mas experimentei como um iniciante completo:

• Eu prefiro a abordagem de Feliz para indentação. Tentei abordagens semelhantes às sugeridas por Isaac, mas como os recuos não são todos 2s / 4s, "às vezes fico pensando nisso". Com Feliz, não perco tempo pensando nisso.

• Se eu estivesse fazendo um elemento personalizado, faria da maneira Fable.React por enquanto. Dei uma olhada em construir coisas "do jeito Feliz" e fugi na hora (vou revisitar em algum momento!).

• Eu acharia muito útil se a documentação priorizasse mais regularmente o aspecto "é como fazer uma propriedade customizada". Acho que é justo aceitar que, com apenas alguns autores, essas bibliotecas muitas vezes terão dificuldade em oferecer uma superfície de API para tudo o que é possível em CSS (por exemplo), então, se um iniciante ficar preso ao não conseguir definir "fontSize" em "em", ou não consegue encontrar "linhas de modelo de grade", ou não tem ideia de que eles devem fornecer algum argumento "Screen.All" - seria bom se eles soubessem como contorná-lo.

• Acho que algumas melhorias na "Qualidade de vida" poderiam ser feitas para começar a eliminar algumas preocupações em potencial ... por exemplo, quando vejo longas listas verticais de acessórios de estilo em Feliz, começo a me perguntar se poderia haver um style.paddingHorizontal e style.paddingVertical . Sei que poderia fazer meus próprios ajudantes, mas este não é o lugar para fazer solicitações de recursos e que pode haver um desejo de evitar a introdução de coisas que não são padrão :)

• Gosto da ideia de abrir a classe Html static no novo F #. De maneira crítica - meus colegas seriam capazes de entender isso quando olhassem por cima do meu ombro - e acho que é importante envolver mais pessoas. Para bancar o advogado do diabo: div não leva muito tempo para digitar e se eu precisar descobri-lo, este é o menor dos desafios que enfrentarei ao usar uma configuração que faz mágica enquanto escondendo Javascript, React, CSS etc. etc. de mim. Geralmente, porém, a descoberta da API é ótima.

• Particularmente para transições / animações em estilos, o jeito Feliz faz muito sentido - muito bom de trabalhar.

• De forma mais geral e provavelmente tangencial: o desafio que eu sempre acerto é em torno de entender onde termina o mundo Elmish e começa o mundo React. Isso não é realmente uma preocupação de nenhuma das bibliotecas - mas como eu não tenho a menor idéia sobre nada do React, o fato de eu poder obter um componente de função de Fable.React ou Feliz me confunde. Claro, aprender isso é minha responsabilidade - mas achei que valeria a pena mencionar. No momento, estou combinando as abordagens Elmish e React e acredito que isso resulte na re-renderização de todos os componentes na atualização - mas não sei a maneira "certa" de fazer as coisas para evitar isso porque exemplos de aplicativos totalmente construídos como este são difícil de encontrar. Às vezes, tenho a impressão de que deveria primeiro aprender a fazer aplicativos React de nível de produção em Javascript, depois me graduar para Fable / Elmish - mas isso parece uma barreira bastante significativa para entrar. Aviso: Não li a documentação do Feliz extensivamente, e ela é muito boa - provavelmente é por minha conta!

Obrigado a todos por compartilhar essas bibliotecas!

Obrigado por sua contribuição @ drk-mtr!

Se eu estivesse fazendo um elemento personalizado, faria da maneira Fable.React por enquanto. Dei uma olhada em construir coisas "do jeito Feliz" e fugi na hora (vou revisitar em algum momento!).

Sim, pode parecer muito assustador no início, mas é muito simples quando você se acostuma. Dito isso, é um custo inicial razoável para o desenvolvedor ao escrever bibliotecas. Acho isso uma troca bastante aceitável, uma vez que a grande maioria dos usuários não escreverá bibliotecas. Felizmente, o trabalho em si é bastante simples, e alguns procedimentos de copiar e colar podem acelerar muito do trabalho (ou, como alguns de nós, escrever geradores para construir o código para nós).

Eu acharia muito útil se a documentação priorizasse mais regularmente o aspecto "é como fazer uma propriedade customizada". Acho que é justo aceitar que, com apenas alguns autores, essas bibliotecas muitas vezes terão dificuldade em oferecer uma superfície de API para tudo o que é possível em CSS (por exemplo), então, se um iniciante ficar preso ao não conseguir definir "fontSize" em "em", ou não consegue encontrar "linhas de modelo de grade", ou não tem ideia de que eles devem fornecer algum argumento "Screen.All" - seria bom se eles soubessem como contorná-lo.

Apenas no caso de você não estar ciente (eu não poderia dizer a partir deste contexto):

Existe um método custom nos tipos prop e style .

Tudo que aceita ICssUnit pode ser definido como: style.fontSize (length.em 1)

Atualizar os documentos deve ser fácil o suficiente.

Acho que algumas melhorias na "Qualidade de Vida" poderiam ser feitas para começar a eliminar algumas preocupações em potencial ... por exemplo, quando vejo longas listas verticais de acessórios de estilo em Feliz, começo a me perguntar se poderia haver um style.paddingHorizontal e style.paddingVertical. Sei que poderia fazer meus próprios ajudantes, mas este não é o lugar para fazer solicitações de recursos e que pode haver um desejo de evitar a introdução de coisas que não são padrão :)

Qualquer coisa que ajude a tornar a experiência do usuário mais fácil é definitivamente bem-vinda em meu livro. Eu adoraria ver um problema / pr para qualquer uma dessas coisas que você notou!

De forma mais geral e provavelmente tangencial: o desafio que eu sempre acerto é em torno de entender onde termina o mundo Elmish e começa o mundo React. Isso não é realmente uma preocupação de nenhuma das bibliotecas - mas como eu não tenho a menor idéia sobre nada do React, o fato de eu poder obter um componente de função de Fable.React ou Feliz me confunde. Claro, aprender isso é minha responsabilidade - mas achei que valeria a pena mencionar. No momento, estou combinando as abordagens Elmish e React e acredito que isso resulte na re-renderização de todos os componentes na atualização - mas não sei a maneira "certa" de fazer as coisas para evitar isso porque exemplos de aplicativos totalmente construídos como este são difícil de encontrar. Às vezes, tenho a impressão de que deveria primeiro aprender a fazer aplicativos React de nível de produção em Javascript, depois me graduar para Fable / Elmish - mas isso parece uma barreira bastante significativa para entrar. Aviso: Não li a documentação do Feliz extensivamente, e ela é muito boa - provavelmente é por minha conta!

Minha experiência no mundo Fable (pré-Feliz) foi que escrevi tudo apenas como funções normais na maior parte, (como um componente para cada .fs). O resultado foi que perdi muitos dos benefícios que o sistema React oferece. Desde que comecei com Feliz, tive que me aprofundar mais em como funciona o React (o que é bom). Desde que me acostumei, eu realmente nem dou mais muita atenção ao assunto. Cada função que escrevo que faz renderização é um componente de função.

Se você realmente quer aprender a escrever React idiomático, acho que é realmente tão simples quanto restringir-se a não usar o Elmish e apenas usar componentes / ganchos de função em seu aplicativo de demonstração. Você pode acompanhar facilmente qualquer coisa escrita em JS já que a API é quase exatamente a mesma.

Ter um aplicativo de código aberto de qualidade escrito em Feliz é definitivamente algo que seria benéfico, eu criei um problema para ele há algum tempo # 67. A coisa mais próxima agora é provavelmente o próprio aplicativo docs ou o Electron Demo do @cmeeren .