This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-08
Channels
- # beginners (76)
- # boot (13)
- # cider (3)
- # clara (7)
- # cljs-dev (254)
- # cljsrn (5)
- # clojure (20)
- # clojure-austin (2)
- # clojure-chicago (4)
- # clojure-dev (7)
- # clojure-russia (5)
- # clojure-spec (18)
- # clojurescript (68)
- # cursive (8)
- # datascript (3)
- # datomic (8)
- # garden (1)
- # hoplon (3)
- # lambdaisland (4)
- # luminus (20)
- # mount (19)
- # off-topic (30)
- # om (10)
- # onyx (8)
- # parinfer (14)
- # precept (7)
- # reagent (9)
- # unrepl (3)
- # untangled (72)
- # vim (4)
- # yada (1)
nevermind... my mistake, my script was at the <head> so the HTML wasn't available š
@tony.kay blog definitely, really interested in how you approach certain challenges. Think you invited as a guest on a podcast would really make my day, since you seem to be getting a lot of things really right, personally really curious about how you got here.
Also as Rich Hichkey pointed out in Hammock development, it's important to research what solutions people came up with for similar problems and build from that. Think this is a bit of pain point in clojure since the community is pretty small. You can find a fair amount of libs but not that many "recipes" and solutions to different common problems.
@tony.kay Regarding ssr & code-splitting, you do make a good point, the complexity added sometimes does not justify the result, when doing something like google analytics, html for the public and for private untangled with no ssr. Is the best way to go.
But if you're trying to build something like yahoo, amazon, ebay. Think ssr & code-splitting provide sufficient value to compensate for the added technical complexity.
The projects I'm working on projects that have a fair amount of complexity both on public & public, and there is substantial shared code between them.
SEO is very important (clients already complaining about indexing status). The codebase is pretty large & we're adding colocated-css, so 1 js file with all the application (private, public) + all the css is really not an option.
Managed to get ssr+code-splitting working nicely with react+redux+reselect+immutablejs+graphql, The ssr & codesplitting complexity was acceptable, but js + so many libraries was not something I want to maintain 1 year down the line :))
SPA + ssr + code-splitting. Imho provides the best user experience for projects that I want to build. So my main focus is how to add this into the app's design from the start, and what would be the best approach to reduce complexity.
also node-js + js. Already have this, with quite a few example-apps to get you started with everything set up. š
I wasnāt trying to say it is never a good choice, just to be careful with the accounting. Every page typically doesnāt need it, because if you have to be logged in, no SEO is going to happen to it anyway.
ah yep. No plans to add it on private links. Gave nodejsit a try, but have enough common sense to not go any further, especially for backend business logic, it just did not stack up to chose it over python (did not know about clojure then).
Will see how it can work on untangled. Think it would also be a nice "marketing stunt", it has the best flow out there, an example of ssr & codesplitting, would make it ridiculously hard to ignore. More community adoption would be awesome š
claudiu: Yeah, itās near the top of my list to show. Any interest in helping with some co-located css augments? The template is using bootstrap, but Iām sure we can find some need for component-local CSS. What would be really cool is to have a way to convert CSS into garden syntax so the bootstrap stuff could be localized onto the components themselves, leading to dead CSS elimination during dead code elimination (donāt use a component? you donāt get itās css)! I donāt have the time to do that amount of css to garden work by hand. There was some talk of conversion tools, but I havenāt seen anything that looked ready yet
Yep sure. Would love to help. So basically to implement untangled-css in some sections of the template ?
@claudiu Clojurescript might be an option if you want to use Clojure and still take advantage of your current code, one of the projects I'm working uses nodejs + cljs on the backend, and I think it's working fine
@wilkerlucio haven't tried. Think that is a major plus of clojure java, nodejs, c# :) . The nodejs was for a personal project just trying stuff out.
@wilkerlucio how much of a impact did untangled-css have on prod build ?
@claudiu I don't use untangled-css
but I like to give it a try, good that you reminded me, I'm just starting a new tiny project, good chance for it š
wow, the library changed quite a lot since last time I checked, I really like the generated css way, I was envying some JS people on the past for that, really good too see that Untangled is taking this approach š
Ahh yes. Played with css-modules, styled components in javascript. Really really nice. Was dissapointed about the lack of options in clojurescript. Ut-css is really a breath of fresh air :)
@tony.kay quick idea: for the CSS protocol, right now I see we have the local-rules and include-children, what if instead of having the include-children we just add classes into the local-rules list? I think the API would be simpler this way
itās for auto dedupe @wilkerlucio
if the thing gets composed from more than once place the composition rules make it easy to see duplication
the older version did it the way you suggest, but since we hand it directly to garden to make css, the dedupe wasnāt easy
I read the old way, what I'm suggesting is simpler than that
let me write a quick code see if I can clarify
;; instead of this
(let [rules (css/local-rules x)
children (css/include-children x)])
;; would be this
(let [rules (filter vector? (css/local-rules x))
children (remove vector? (css/local-rules x))])
;; I used vector? because was easy to remind, but better which a check to see if it's a classinternally would be the same, I'm just as an user thinking having a single method to implement can work better on this case
claudiu: Yeah, itās near the top of my list to show. Any interest in helping with some co-located css augments? The template is using bootstrap, but Iām sure we can find some need for component-local CSS. What would be really cool is to have a way to convert CSS into garden syntax so the bootstrap stuff could be localized onto the components themselves, leading to dead CSS elimination during dead code elimination (donāt use a component? you donāt get itās css)! I donāt have the time to do that amount of css to garden work by hand. There was some talk of conversion tools, but I havenāt seen anything that looked ready yet
; then instead of this
static css/CSS
(local-rules [this] [[:.items-wrapper {:background-color "blue"}]])
(include-children [this] [LineItem])
; user whould write this
static css/CSS
(local-rules [this] [[:.items-wrapper {:background-color "blue"}]
LineItem])@wilkerlucio So, weāve kept the old way around because I donāt want to break existing users. You should chat with @timovanderkamp a bit about it, because he probably remembers our design dicsussions better than I do on the latest version (he did the coding). Iād be happy to entertain a new namespace in the lib that does it that way, and you can pick or choose. It is a tiny library, so having some options is actually kinda cool as long as the docs are clear about the different styles.
ok, but really, it's just about the front-most interface, going down the design would be the same
I would like to hear what @timovanderkamp thinks on it, so please let us know when you are available Tim š
I like the way it is, primarily because it give a really nice separation between rules that youāre defining for the component vs. ones you want to ensure are available. Itās just cleaner and clearer to meā¦and also makes each of the internal algoritms clearerā¦no need for extra filtering steps
Iāll be adding some co-located CSS in the template soon, and Iāll probably form some stronger opinions once Iāve used it more. That library was originally an āexperiment with promiseā that I havenāt used much personally yet.
yeah, fair point there, also I can macro this out if really want to š
I still consider it an experimental feature, but with Om *instrument* Iāve yet to find a great use-case for it.
what defui augment?
you have to write them in clj since they are augmenting macro behaviorā¦but you can wrap render, add lifecycle, implement interfaces, etc.
I didnāt pull this over yet into the new repo, but the example will work with the new lib.
with these as the augments (not defined in new lib, but would work with new lib): https://github.com/untangled-web/untangled-client/blob/develop/src/untangled/client/impl/built_in_augments.clj
two kinds of augments: wrapping and augmenting. Wrapping lets you wrap a method so that you can move a wrapping concern elsewhere (but that is doable with simple function composition as well). The augments let you provide protocols and methods.
sounds interesting, and scary at the same time
yeah. Like I said, it is experimental, and could disappear. My original intent (because we made it support dev mode vs production mode) was to have it optionally mix in dev tools on each component
like āclick on the UIā to send a ājump to sourceā command to your IDE via figwheel
kind of like macros in general, I think this might have genuine use cases, but it should be like last resort things in order to avoid adding too much complexity
humm, I like the tooling ideia, but as you said, instrumentation might solve that
have a nice ride š
@wilkerlucio i think the main reason for seperate functions was so that it is more clear what rules are the local rules for the component itself, and what rules do you include from other components
thanks, we, in the end I agree with you guys, my suggestion is more a syntax sugar, can be macroing out, or just get used to š
But it forces you to write another line of code indeed, eventhough you might not want to include any children at all
Yea, i mean the seperate protocol for global rules is not that necessary either since you can prevent localization with a $prefix
timovanderkamp: about the global rules, I actually enjoy those being separated, I think it makes very clear when you want to do sometime more globally scoped š
But like i said, it makes it more clear what youre doing i suppose
I agree with you though, while programming i found the seperate method a bit annoying but not in a way that it bothered me too much, maybe others who work with untangled-css have experienced this aswell?