looks really nice. 🙂

A few ideas that come to mind:

- The width seem a bit small. (personal preference since I view it on wide screen)

- Would be really nice if "Become a patron" could be Support untangled. And there could be other options along with patreon. Thinking maybe I could convince my company for a donation, not that sure about a monthly commitement.

- Beside "Companion projects", would be nice to see community projects.

- A lot of people will get to untangled after om-next, and already see posts "untangled is a version of om next that's easyier but more limiting". Think would be really awesome to point out the differences as soon as possible. And what are the benefits/tradeoffs

- When pitching untangled would be really nice to have a roadmap. (including what's being developed now and what's the focus for the future)

- Would also add om-css. A bit of a missing feature when coming from javascript where you have. css-modules, styled-components etc... for co-locating css with react components

- Really think BDFL is the way to go in general. But would be nice to have references to community/contributors (past&present) ex: Made with ♥️ by X (@xtwitter) and contributors (with links). The question will surely pop up: "what if, personal problem and 1 month can't work, what happens to the project. Bugs, pull-requests, etc..."

- Blog with rss feed would be really nice (especially for news & maybe case studies from people using it on projects)

- If consulting is an option. Would really be a plus to add it there. Often get stuff like "what if you get stuck since you haven't built any large projects with it". A clear pricing model would be really nice.

- For larger contributions would be really cool to offer some logo space somewhere.

- A list of "how's using it" or "projects made with untangled" would be really helpfull. (like: x website is built with untangled, really similar to what I'm trying to do)

- Personally would emphasize slack channel as much as possible (seems like a key piece for building a community). On par with fork me on github something like "join as on clojurians slack #untangled "

- Videos would be really cool to have a page in the website with embeds. List both and separate conference talks from dev screencasts videos.

- Getting started as nav link (personally I was expecting a "getting started" in the menu bar that would contain guide links, docs, videos, etc...)

In my particular case I would be interested to see a “from om-next to untangled” guide. I know that om leaves parts of the design fairly open so it may not be possible to treat it in a guide. Agree with the points of claudiu otherwise 🙂

@tony.kay Regarding the "community resources". I have a few "must-haves" and personal preferences about how apps I build should be. Most of them probably differ from common use-cases, and don't know if they will or should make it into untangled-template. I think the're nice but they do add a lot of noise, to many features tied together could make it unnecessarily hard to understand what's going on, and how the features you care about work.

Was thinking (how to add community value). To create a repo from untangled-template (keep it as similarly as possible), tweak it and add the features I will use when starting new projects. When I add something new just post the link to the pull request and see if it's worth porting to untangled-template.

That way people that are new could like find a boilerplate that's already configured, and has all the features they will need to get started. Also nice for sharing ideas about flows and what's possible.

Seems like a win win. For me in getting feedback, bug-fixes, new ideas. For the community because if there will be a few similar projects, people could get started much faster and not have to figure out stuff, that others have already found solutions to (in private repos).

What do you think ? 🙂

Hm, I find that I have a (perceived) need for quite an involved composite datastructure representing a tree. It has its own API. So at the moment, in the test app I'm writing, it ends up being a leaf of the untangled state where it ends up not utilizing idents or queries, but represents a large part of the UI. Now, I'm not quite sure what I'm looking for in terms of an answer, I just thought people might have useful comments.

Previously I had been trying to fit what the datastructure does into various state management systems others have developed. It never seemed to quite be what I wanted, so I ended up just writing something custom.

Oh, also. Cool website. I find the spreadsheet very useful. Would like to see some mention of using untangled only on the client and what that means.

+1 for client only untangled example

@urbank Think most of what is need for client only is covered under Legacy restful api. https://github.com/awkay/untangled/blob/develop/GettingStarted.adoc#using-a-legacy-rest-api

the complex datastructure as a untangled leaf sounds pretty interesting. Think for a good comment, sharing a minimal sample app with the code, and a bit of description about the problem you're trying to solve, would be the best bet 🙂

@claudiu That link about the REST api is great. Explains everything. I figure there must be some significant portion of clojurescript users who don't work with a clojure backend. So I think it would be a good idea to feature that somewhere on the website IMO

And yeah, I'll try to post an example and more details later in the day regarding the complex datastructure as leaf

@urbank Yep, also noticed the part that people don't really do clojure backend, server side rendering or code splitting that much. Personally think it's mostly because of the lack of resources available and the maturity in tooling.

I'm just stubborn and want this for a personal project (no deadline). But so far spent a lot of time and haven't gotten all that far with server side rendering (a nice flow with remote data, routing, code-splitting). So guess it's not being used since you have to fill in to many missing pieces, and the feature benefits ought-way the dev time needed.

SSR think would be a killer feature for untangled that would set it apart from the crowd. 🙂 Rum seems to work nicely but it's a bit to bare-bones.

@claudiu we do SSR with untangled-css and it is insanely powerfull

I need to get that lib pulled over to the new github location

too many things to do 🙂

@mitchelkuijpers wow awesome. Do you also render the page and it's content (bascially generate the app-state on the server put it in html and load it in the client) ?

@claudiu Any suggestions on an alternate theme? I agree that merlot is a bit narrow. I liked the heading, but the body is a bit tight.

https://github.com/pages-themes

@claudiu yes!

@mitchelkuijpers Oh. Any change o there existing a minimal repo out there with how you built it, article, anything ? Know initial-state-app was not server-side-friendly, think it's fixed now, haven't gotten around to testing the fix in my boilerplate.

@tony.kay Will check it out 🙂 Maybe help with boring stuff if there's something that needs doing.

@claudiu I'll try to get to writing a blogpost about the things we had to solve. The biggest thing was the initial app-state indeed

@mitchelkuijpers That sounds really awesome. Trying to build up my boilerplate for future projects, ssr & untangled-css ar part of it. Would definitely help me a lot, probably a lot of other people also.

maybe we should create untangled-ssr 😛

Actually moving the state from server to client was the biggest thing

the co-located CSS library is moving. New name/URL is https://github.com/awkay/untangled-css. The dependency itself is not being renamed in clojars.

The rest just works if your files are cljc

And we use untangled-css for moarr performance for the initial render. We can only include the css for the rendered page

:)) well I was thinking of basically doing a small fictive project. With ssr, u-css, and all the recepies in the untangled cookbook. So basically to get started you just run the code and can hack away at it learning as you develop your project (more or less).

Yeah that would be cool

I would be happy to help/review

I have do to it for my projects anyway. Something like that would have saved me so much time. Especially since I like to learn by hacking away at code and rebuilding it 🙂

to me one of the strongest points on Untangled vs Om.next stock is how to handle remote data load

having it explicitly was a game changer IMO

@claudiu we do this for the initial state btw:

(defn initial-state->script-tag
  [initial-state]
  [:script {:type "text/javascript"} (str "window.INITIAL_APP_STATE = '"
                                          (util/transit-clj->str initial-state)
                                          "'")])

ahh yes 🙂 my problem was that on server it only had the active page, it was not the complete intial-app-state with data from all the union queries (router).

Maybe you want to do that and then just merge it in somehow

We want to run the union memoize it and then create the state for the rendered page

What I was thinking: Server generates the app-state with all routes state & page data if needed. Client side code just mounts on the html & just uses the app-state from server(no get-initial-app-state call). After that client code takes it from there, until a refresh.

Yes that is what we do

Just a thought no idea if it will work or if it's an ok approach. Building on that approach. Multiple apps main. blog, account; a "dispatch layer" that know about modules & routes. On server can create a merged app-state from all modules, and on client they can be loaded on demand. And have code-splitting without losing the benefits of union-queries.

Did not think of that but that is a really good point ^^

Btw we use this small trick for client-side only state

(initial-state [this params]
    #?(:cljs (merge {:ui/company-autocomplete (uc/initial-state entity-auto-complete/CompanyAutoComplete nil)
                     :ui/contact-autocomplete (uc/initial-state entity-auto-complete/ContactAutoComplete nil)}
                    (utils/transit-str->clj js/INITIAL_APP_STATE))
       :clj {}))

ahh, intersting.

You can put that into your root component 😉

And maybe in the clj case you add the initial state of the router

https://github.com/awkay/untangled/commit/41e12b8a01e2502b5f335e6937a1ef90aea3f0f3 -> haven't tested it but tony seems to have fixed, initial state for server.

Yeah I noticed that too

And I would memoize the union on the server

@claudiu I did a lot of your suggestions to the website…should update shortly. @mitchelkuijpers has offered to sick his designers on it and make it look more better 🙂 Added testimonials as well.

@tony.kay awesome 🙂 so so cool how fast things get improved in untangled.

@claudiu Regarding if anyone wants to be a “large contributor”: I’m glad to include their info on the website 🙂

awesome 🙂

@urbank Having a blob at a leaf is fine, and is sometimes just what you want for reasoning and performance.

@nha Did you see the page on the new website: https://awkay.github.io/untangled/vsom-next.html

@tony.kay Did you like just write it ? 🙂

no, it is a link on the main page…wrote it yesterday

Will really help me out when comparing untangled with javascript solutions (most of it applies but on a larger scale than om-next ) 🙂

looked through all the github-pages templates. The one you chose is definitely the nicest.

Sounds like I’ve got some volunteer designer help

🙂

in the Spreadsheet did you give untangled a 10/10 for code splitting ?

I don’t remember.

It is more of a cljs feature, so whatever you think of Closure’s support is what you should use 🙂

It’s really just meant to give you a more objective way of looking at your tools. I’ve used that technique to pick programming languages, tools, etc.

It’s too tempting to go for “sexy” or “easy” and not think of the facets that are really important but don’t bite you until you’ve got 10,000 lines of code and aren’t going to switch

ohh 🙂 really not very happy with cljs codesplitting 😄. Glad to see that it is going to be improved soon https://gist.github.com/swannodette/6150d4213aeb9eba31e03ae522af4425 .

really nice & helpfull. Bookmarked 🙂

That does look nicer. I was always pretty happy that the code splitting was there.

more wrappers is nicer. That’ll make it easier for me to improve the i18n locale loading.

But think for untangled, doing code-splitting without a merged state of all pages passed from server. Seems like you will miss out on some features. Or is the impact pretty low ?

I would not merge state from server.

You can always pull state from a component and use Om’s tree->db to normalize it. So, initial app state can still apply…just use it from within the mutation that triggers after your code is loaded

the mutations are just symbols…defmethods that run during the load would extend your mutation set

you can target one of the incoming mutations (perhaps with a naming convention)

then (om/tree->db NewUI (uc/get-initial-state NewUI)) will give you something you can merge to app-state

and (om/set-query!) can be used to dynamically update the UI query where that new thing should appear

Server (persisted) data: I would generally load that with a load

But, all that said, I really don’t care too much for SSR once you’re logged in. It’s fine for initial pages and not-logged-in SEO stuff (though I typically feel like doing those parts with plain HTML and templates…why use a hammer for a tack?). The benefit? Smaller code size? Network speeds are always getting faster, and caching eliminates the overhead after one visit. The cost: lots of added complexity in your application. Bookmarkable? I’d much rather see a “loading” bar and then have the application do all of the processing once it is loaded (like the template does). The amount of complexity you’re adding into your code-base to support saving a second or two is really bad accounting if you ask me. Your users care about features, not about how you rendered the darn thing.

I guess you’re right…I do need a blog 😄

then I could rant just once 😉

Would be interesting to see support for client-defined parsers. We’re writing a pretty client-heavy data manipulation app where lots of the data is derived as a view off of the app-db. Right now we handle that by running mutations occasionally to keep views of the data in-sync but control over the parser would result in something a bit cleaner. We’ve been kicking around the idea of conditionally dispatching to a custom defmulti based on the existence of keys in the defmulti registry, but if there are any other ideas out there I would love to hear them.

@gardnervickers does what is proposed in https://github.com/awkay/untangled/issues/9 look like it'd solve it?

@gardnervickers I’m implementing it right now. Actually, implementation and tests done. Writing docs now….well, I just thought of one more test…

OK, custom read handler now supported. See M10-Advanced-UI in the devguide on the develop branch. Deployed to clojars as 1.0.0-beta2-SNAPSHOT

try not to tangle up your apps too much with that 😉

If anyone sees the sections of the docs that say we don’t allow this, feel free to fix them 😄

@tony.kay again I'm having problems with initial render on a new project, that's super weird, it never happens on old projects, but when I start a new one it gets hard to make the initial render works

the started-callback get's triggered, but the UI doesn't render the initial thing