Fork me on GitHub
#fulcro
<
2019-01-16
>
wilkerlucio00:01:31

@d4hines I like to add a few more things about EQL that might not be obvious, and that is that EQL supports multiple dimensions of information, I like to expose a little about it here, the first dimension the entry itself, like :foo, this gives the first information level and that's what people use most of the time, the second dimension is the parameters, if you do some generic implementations on the parser the parameteres can provide a whole language on top of it, adding features like filter, pagination, or anything really, I think the current best example of this is Wakable, that uses params to allow users to express things they normally would though SQL. The third dimension I think most people are unaware of, is that at each "query level" (the vector that holds attributes) can also have meta-data embeded, this allows for a "group level" dimension of data, Fulcro uses that to store from which component that query belongs and that's what allow normalization, I recently have been playing with using that to setup generative configuration for generated data from queries, this way each component in fulcro can define details about how its data should be generated (that includes things like overriding generators, defining size of generated collections, predicates that validate if the generated data is ok....). So I think that still a lot of hidden power to explore in EQL, its very expressive once you understand how to use all the pieces

Daniel Hines15:01:02

Ah, this is helpful. I'll have to investigate some of these examples a bit more. Thanks.

wilkerlucio00:01:56

and EDN has more to offer to EQL, for example, there are no usages of sets in EQL, in the future it could mean something, tagged literals is even another possible layer to extend in, I don't think we should do any of this now, I'm still to find a case where I can't express things with the current EQL, but it makes me feel comfortable that we still have room to extend if it makes sense in the future 🙂

j1mr10rd4n03:01:58

@tony.kay - further to the work on https://github.com/fulcrologic/semantic-ui-wrapper/pull/7 and our discussion, I’ve pushed a branch at https://github.com/fulcrologic/semantic-ui-wrapper/tree/optimise-for-shadow-cljs if you get time to have a look please I went with a strategy of splitting the factories into different jars: semantic-ui-wrappers is unchanged for cljs users and a new semantic-ui-wrappers-shadow jar offers the individual factory namespaces for shadow-cljs projects

tony.kay15:01:30

Wondering why you felt the need to go all the way to separate jars? Why not just separate packages?

tony.kay15:01:54

Did you do a test and find that figwheel/standard compiler puke if those files are even in the library?

tony.kay15:01:29

Other than that, the code looks excellent

tony.kay15:01:22

I guess the split makes it a no-brainer on getting the best out of shadow…I just don’t love seeing libraries that imply that adopting shadow “splits you” from the main community….bad PR

tony.kay15:01:32

Thing is, shadow will support both, so misusing it in shadow would just mean a bigger build. If misusing it in cljs is correctable by removing one require and adding a diff one, then I think it is better community mojo to keep them in the same library.

j1mr10rd4n16:01:35

yes I tried separate packages first and the standard cljs compiler barfed at the ‘require :default’ lines - and i couldn’t find another way to exclude them

tony.kay17:01:54

cool…then it seems like the right way to go

thosmos22:01:37

Would it work to generate a separate foreign-libs reference for each js file in a deps.cljs file? This might make it available for non-shadow-js users?

thosmos22:01:56

or is this the standard cljsjs route?

tony.kay22:01:26

good questions…I’ll defer to @U0J0AC1AT

j1mr10rd4n02:01:44

it might be the start of an approach - the current cljsjs version of semantic-ui-react is packaged as a single minified file - i think the boot build process would have to be altered to preserve the individual modules for a finer-grained deps.cljs

Reily Siegel15:01:22

I am having some issues using material-ui's TextField with fulcro. I seem to be having [this](https://github.com/reagent-project/reagent/blob/master/doc/examples/material-ui.md) issue for which a reagent fix is available. How would I go about fixing this in a similar way for fulcro? I attempted to translate the fix over myself, but ended up with reagent errors about components be passed both value and defaultValue.

tony.kay15:01:23

@reilysiegel the wrapping problem has been solved for a while in Fulcro. The problem of the input being deeply nested is actually already fixed in Fulcro’s wrappers on 2.8.0-SNAPSHOT…just merged thta PR a few days ago…be lovely if you’d try it out.

Reily Siegel15:01:50

Sure, ill give it a try!

tony.kay15:01:43

Also take a look at the semantic-ui-wrappers project…Jim has been working on a branch targeted at shadow, but it shows usage on an external js lib

tony.kay15:01:03

This is the core of the issue on inputs, local state, round-trip (app state) updates, and React for anyone interested in why inputs can behave in truly awful ways: https://stackoverflow.com/questions/28922275/in-reactjs-why-does-setstate-behave-differently-when-called-synchronously/28922465#28922465 Fulcro encourages you to use transact, which to React is an async update of the field…the wrapper does some behind-the-scenes trickery to make it work as best it can.

tony.kay15:01:01

Here is the github issue (marked “invalid”, because it is sort of baked into React that way): https://github.com/facebook/react/issues/955

Reily Siegel17:01:46

After further investigation, it seems like the issue still persists even with the latest snapshot. However, my issue seems to be different from the ones you linked to. By default, using the material-ui input works fine on desktop, but on mobile has some strange effects. For example, trying to type "Clojure" into a material-ui input field results in "CClCoCCljCClCouCClCoCClje" in the input. However, if I apply the fix detailed in the reagent wiki, that issue stops, but I get errors from react dom about defaultValue.

j1mr10rd4n20:01:48

Would you be able to share a minimal project that demonstrates the issue in isolation?

Reily Siegel01:01:00

The project I'm currently working on is still pretty minimal, and based on the lein template. You can find the code at https://gitlab.com/ReilySiegel/flexblock/tree/fulcro. All of the relevant bits are in https://gitlab.com/ReilySiegel/flexblock/blob/fulcro/src/main/flexblock/ui/material_ui.cljs and https://gitlab.com/ReilySiegel/flexblock/blob/fulcro/src/main/flexblock/ui/users.cljs. It is current using the working example with a warning,but if you uncomment the line (def text-field (factory material/TextField)) in material_ui.cljs, it will overwrite the fix definition. Note the the broken behavior only happens on mobile browsers.

Reily Siegel01:01:46

If it helps, I am doing a complete re-write from re-frame/reitit, and I also experienced this problem with reagent, but didnt get the warning with the fix applied.

Reily Siegel17:01:39

react-dom.development.js:507 Warning: wrapped-input contains an input of type text with both value and defaultValue props. Input elements must be either controlled or uncontrolled (specify either the value prop, or the defaultValue prop, but not both). Decide between using a controlled or uncontrolled input element and remove one of these props. More info: 
    in input (created by wrapped-input)
    in wrapped-input (created by flexblock$ui$material_ui$input_component)
    in flexblock$ui$material_ui$input_component (created by InputBase)
    in div (created by InputBase)
    in InputBase (created by Context.Consumer)
    in WithFormControlContext(InputBase) (created by WithStyles(WithFormControlContext(InputBase)))
    in WithStyles(WithFormControlContext(InputBase)) (created by Input)
    in Input (created by WithStyles(Input))

thosmos22:01:25

I'm creating an autogenerated CRUD editor for some data-defined types of things. I'd like to create some different component types each with a unique ident, query, and render-fn. would either of these forms be reasonable?:

(defn create-component [ident query render-fn]
  (om/sc [this props]
    {:ident ident
     :query query}
    (render-fn this props)))

(defsc Meta [this props {:keys [ident query render-fn]}]
  {:ident (fn [] ident)
   :query (fn [] query)}
  (render-fn this props))