Clojurians Log v2

@tony.kay did server side rendering also make it in ?

@tony.kay The ui routing helpers are awesome

@claudiu Server side rendering was already included from 0.6.1, so it is definately in 0.7.0

@mitchelkuijpers good to hear you're already using them. I plan on getting the form state support from untangled-components documented and polished for a release of that in the coming days.

We’re just about to go live with our Untangled application and we wanted to thank the Untangled team for all your help over the last couple months. We’re compiling/simulating Onyx jobs inside the browser on every keystroke, allowing interactive collaboration on distributed processing jobs. Untangled and Om.next were integral in getting performance right without sacrificing maintainability.

We have a blog post up with some examples of the UI and a more in-depth explanation of what Untagled has allowed us to do. http://www.onyxplatform.org/jekyll/update/2017/02/08/Pyroclast-Preview-Simulation.html

Yeah, cheers everyone. There’s no way we could have built this in a sane way on plain React.

bravo !!!

@gardnervickers @michaeldrogalis @baris @therabidbanana @wilkerlucio @currentoor @mitchelkuijpers I'm about to start an effort around our style kit and component libraries. Right now, you have to use things like blueprintjs for styled react components in Om/Untangled (and accept the subsequent overheads and pains) or write you own. We have built our own (tunable) CSS (untangled-stylekit) and have started the project untangled-components. The latter meaning to be support for pre-styled Untangled-ready components (with queries, mutations, CSS, etc.). Currently we have calendar. I'm asking the community for help building these out. Each component will probably take about 1-2 hours. The CSS is already written, the DOM is already written/documented. Really, it is codifying the DOM into defui with an ident, data model, mutations, and callbacks. (e.g. see https://github.com/untangled-web/untangled-stylekit/blob/master/src/main/cards/styles/objects.cljs for the DOM/CSS that is prewritten in devcards). This and the forms support will make rapid application development with Untangled a true force to reckon with!

We're putting together our list of "priority order". We'll be adding issues on that project, and then knock them out. Please let me know if you can space a few hours to do one or more. I'm asking everyone to build them via devcards so we have visual regression abilities and built-in documentation.

oh...and we have an image library with pluggable metadata/image storage, and image clipping.

@tony.kay: I'm happy to help. Actually I'm pretty timed with other stuff, but I'll see what I can do. I'll take a deeper look at the weekend.

sweet. I'm organizing at the moment. I'll try to have enough docs on the develop branch of the project to show the patterns. It should actually be a lot of fun

Yeah, that's sounds awesome. I'm actually gonna try and need to use the form support and also the image lib components

Spent too much time on developing the nested router functionality which you published yesterday...argh could have saved so much time

I'm beefing up forms docs now

sorry it took so long to show routing 🙂

too many things going on

@tony.kay Sure I'll make some time, have little now since I am moving

@mitchelkuijpers thanks 🙂 I'm trying to motivate our staff to start chipping away at these..too much copy-pasting going on at the moment

Hate that we have other teams who do Elm or Angular and they do the same.. They would never do that on the back end...

I promise to publish snapshots of these in rapid fire.

you're using Elm and Angular AND Untangled??

Our company we have different teams with different projects

I think we should try to bring a CRUD example in the cookbook with using the new form and image components and also the hole plumbing with the server side and with the classic overview table and detail form for any "entity"

holy moly that's a lot of aggressive UI tinkering...Elm is cool, but wow

@baris love to have that contribution 🙂

Angular is so bad for java developers that elm is worth it. Angular is becoming legacy

oh I like Elm...just surprised you talked your company into it AND Om Next

I thought I was pushing it

😉

Hehe 😁

I don't make such cool frameworks

😊

I would love to use stylekit and then we would need to give it an aui (Atlassian) sauce

So will keep a close eye

I don't know the benefits of the untangled stylekit need to take a deeper look. I'm using http://bulma.io for styling

@baris We chose to make our own as opposed to using an external CSS framework because we didn't want to target our components and UI on an externally moving target. We have responsive support, grid, flexbox, etc.

was kind of a tough call, actually

but kind of hard to make reusable components without making some kind of concrete CSS decision, since it affects your DOM layout

would also be relatively easy to drop components into untangled components that use other CSS...e.g. a bootstrap package, a bulma package, etc...each with components for those CSS frameworks

might bloat it a bit, but Closure takes care of that

I'm on the go. Talk later and how I can help and contribute to push untangled

k

Different time zone here in Germany :)

Now that I'm thinking of it, we could make some kind of state propertly like :ui/style accept things like :native, :bootstrap, :bulma, etc....separate the interface/model from the rendering, then plug in alternate renderings for each component.

anyway...downstream

That was something I already thought about

cool, I think I can tackle some components over the weekend too, I guess we can keep using this room for coordinating it 🙂

absolutely. Thanks! I'll do one like button today, to establish the pattern

we can use github issues and PRs to coordinate consistency

@tony.kay I was just looking at https://github.com/untangled-web/untangled-stylekit/blob/master/src/main/cards/styles/objects.cljs, can I suggest we start using indentation with 2 spaces as default and make it the standard? having it on the second argument makes it to use a lot of space very quickly, what you think?

Unfortunately, that is the default formatting Cursive does, unless you manually edit the setting for every dom function

and everyone here uses Cursive

but I completely agree with you, and on my own machine usually go through the effort of setting it

looks like cursive has a setting for it 🙂

just found it

Default to Only Indent

I'll have to take a look to see what exactly is involved with building out components, but should be able pitch in a bit.

@therabidbanana @wilkerlucio @baris @mitchelkuijpers This video is basically what I'm thinking. Shows doing it for a bootstrap menu: https://www.youtube.com/watch?v=uxI2XVgdDBU&feature=youtu.be

@tony.kay cool, I'll check on the video later, about the ident, we can have the wiki with guidelines, I believe just by having the code in a certain format will already drive people to follow, for the ones unaware we can point out on pull requests, do you agree that its better than having a bad indentation just for editor configuration convenience?

@tony.kay Have you dropped the idea of co-located css from om-css ?

On untangled components: I'm wondering what opinion people have of the standard way to make reusable components that have queries and need om/computed and additional out-of-band parameters. You'll want to compose the component's query into your own, and then for example, say you want to render a button and we supply ui-button React factory. We might want to take onClick as an additional named-parameter: (ui-button (:my-button props) :onClick do-thing) => converted into a factory call with om/computed on the callback bit But then you might also want to add additional top-level attributes (like css classes and such): (ui-button { :className "boo" :onClick do-thing } (:my-button props)) which takes the first arg and turns it into js props and om/computed things Or should we just make you specify things like style additions as part of the app-state that is part of the component's internal query, and just have you use om/computed manually? (ui-button (om/computed props {:onClick do-thing}))?

e.g. the style would be in the state and you'd query for it: (defui Button ... (query [this] [:button/style ...]))

then have a "button state" constructor that can be used in InitialAppState (make-button :style :big :left-icon :left-arrow)

Oh, and then i18n.

for example, if you do (make-button :label "Boo") and then in the rendering do (dom/span nil (tr-unsafe label)) you will miss the extraction

but if you do (make-button :label (tr "Boo")) you'll get the extraction, but at runtime if you started out with an alternate locale the key will be wrong at the tr-unsafe.

We added tr-lambda as an attempt to deal with this, but the renderer needs to know that it is getting a function, not a string.

(make-button :label (trlambda "Boo")) must be rendered in the component as (dom/span nil (label))

I guess we could support both? Something like :label means literal string, and :labeller means a function that returns the label?

that way the non-i18n user doesn't have to think about it

We could also do the very first version (make-button :label "Boo"), always call tr-unsafe on the internals of the component, and let them know that to get string extraction they should write some throw-away function somewhere that is never called that simply calls tr on all the labels they'd like extracted.

or we could make a tr-extract that is identity, but can be used to ensure string extraction happens: (make-button :label (tr-extract "Boo"))

I think I like :labeller best personally

oh wait...forgot..cannot put functions in app state

@tony.kay have trouble using untangled-stylekit

I’ve cloned the repo, and done the npm/gulp setup

I'm working on the components project to just have the css there already...let me push on develop...

oh, and make sure you're using the develop branch(s)

I am

its a react error =>

I restructured the untangled-components to have two builds: guide and visuals

React.createElement(...): Expected props argument to be a plain object. Properties defined in its prototype chain will be ignored`

one of our devs is working (actively) on stylekit...he may have pushed something broken (hope not, but possible)

ahah, no problem, that’s awesome of you to open-source it !

stylekit is currently not externally polished. So, I don't recommend using it just yet. Give us a couple more weeks of getting components going full-steam, and the docs/tools ramped up on the style kit

so the main goal is to provide basic components to be easily usable right ?