Fork me on GitHub
#untangled
<
2017-02-08
>
claudiu10:02:40

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

mitchelkuijpers10:02:50

@tony.kay The ui routing helpers are awesome

mitchelkuijpers10:02:17

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

tony.kay16:02:52

@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.

gardnervickers17:02:56

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.

gardnervickers17:02:43

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

michaeldrogalis17:02:05

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

tony.kay18:02:52

@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!

tony.kay18:02:13

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.

tony.kay18:02:01

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

baris18:02:25

@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.

tony.kay18:02:08

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

baris18:02:29

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

baris18:02:11

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

tony.kay18:02:14

I'm beefing up forms docs now

tony.kay18:02:26

sorry it took so long to show routing 🙂

tony.kay18:02:36

too many things going on

mitchelkuijpers18:02:20

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

tony.kay18:02:07

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

mitchelkuijpers18:02:26

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

tony.kay18:02:47

I promise to publish snapshots of these in rapid fire.

tony.kay18:02:57

you're using Elm and Angular AND Untangled??

mitchelkuijpers18:02:23

Our company we have different teams with different projects

baris18:02:52

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"

tony.kay18:02:54

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

tony.kay18:02:12

@baris love to have that contribution 🙂

mitchelkuijpers18:02:44

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

tony.kay18:02:20

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

tony.kay18:02:36

I thought I was pushing it

mitchelkuijpers18:02:11

I don't make such cool frameworks

mitchelkuijpers18:02:55

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

mitchelkuijpers18:02:25

So will keep a close eye

baris19:02:19

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

tony.kay19:02:14

@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.

tony.kay19:02:27

was kind of a tough call, actually

tony.kay19:02:51

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

tony.kay19:02:19

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

tony.kay19:02:38

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

baris19:02:59

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

baris19:02:29

Different time zone here in Germany :)

tony.kay19:02:54

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.

tony.kay19:02:27

anyway...downstream

baris19:02:32

That was something I already thought about

wilkerlucio19:02:48

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

tony.kay19:02:21

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

tony.kay19:02:50

we can use github issues and PRs to coordinate consistency

wilkerlucio19:02:29

@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?

tony.kay19:02:54

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

tony.kay19:02:05

and everyone here uses Cursive

tony.kay19:02:25

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

tony.kay19:02:00

looks like cursive has a setting for it 🙂

tony.kay19:02:03

just found it

tony.kay19:02:09

Default to Only Indent

therabidbanana19:02:39

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.

wilkerlucio19:02:30

@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?

claudiu20:02:23

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

tony.kay21:02:10

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

tony.kay22:02:24

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

tony.kay22:02:10

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

tony.kay22:02:48

Oh, and then i18n.

tony.kay22:02:29

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

tony.kay22:02:15

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.

tony.kay22:02:11

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.

tony.kay22:02:46

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

tony.kay22:02:41

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

tony.kay22:02:54

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

tony.kay22:02:08

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.

tony.kay22:02:53

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

tony.kay22:02:20

I think I like :labeller best personally

tony.kay22:02:56

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

baptiste-from-paris22:02:40

@tony.kay have trouble using untangled-stylekit

baptiste-from-paris22:02:02

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

tony.kay22:02:12

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

tony.kay22:02:28

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

baptiste-from-paris22:02:00

its a react error =>

tony.kay22:02:15

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

baptiste-from-paris22:02:16

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

tony.kay22:02:54

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

baptiste-from-paris22:02:35

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

tony.kay22:02:55

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

baptiste-from-paris22:02:07

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