Clojurians Log v2

figwheel is not seeming to work when running the todomvc client-only, and I'm getting an error code in chrome...

any thoughts?

@macrobartfast cannot reproduce, i ran on 1d35cdb origin/client-only

$> lein do clean, repl
(start-figwheel)

any other steps maybe?

oh, @macrobartfast, it looks like you were going to index.html as your code is minimized

if that’s correct, you had a bad cached version

if you reload with cache off you should get a 404

badaboom... 'do clean' did the trick! thanks @adambros !

just ran the server version... everything has worked out of the box for both the client-only and server versions... this is awesome!

pretty wonderful to be able to have all this working for me so quickly. 😀

@baris Thank you for you reply.But did follow the Screenshots(two repl),and the http://localhost:3000/index-dev.html shows content (the login form). But the figwheel prompt did not connected, and the chrome console repeatedly show: WebSocket connection to '<ws://localhost:3449/figwheel-ws/dev>' failed: Establishing a tunnel via proxy server failed.

So, that message means that figwheel isn’t running where the js expects to find it

When you start the server on port 3000 with (go), that starts the server-side web server for the application.

The js has generated.

Figwheel is a tool that compiles the JS AND runs a websocket

it is started from the other REPL

(and shows a message that tells you figwheel is compiling)

If you’re seeing that error you either have an old cached version of the JS or figwheel isn’t running

yes all three js has compiled, dev cards test.

open dev tools in chrome and "disable js caching while devtools is open" in the settings

reload browser

did that.

do you have some weird network configs? proxy server? "Establishing a tunnel via proxy server failed."

that might just be a secondary error of figwheel…don’t know

See: http://developer.dynamsoft.com/dwt/kb/2891

maybe need to bypass proxy server?

well, that would have made the other page fail too I think

try loading from localhost:3449 and see if you get any response…the full stack ops won't work there, but it will tell you if figwheel is up

ok,let me try through from beginning again.

basically that is all there is to it: figwheel runs, generates (and instruments) js code with hot code reload capabilities (to be provided by figwheel on port 3449). You, however, run the server at :3000 for full-stack ops. Your code talks to port 3000, and the instrumented figwheel stuff hits 3449

the figwheel port can be configured in the figwheel section of the project file

I double-checked…it is not.

oh, make sure you’re using the develop branch

I think…let me check that

is disabling js caching different than the usual devtools settings/preferences/disable cache... ?

actually master and develop are identical

@macrobartfast that is exactly what I mean, yes

it just ensures you don’t get old cached code

ah cool, thx

You are aware of the YouTube getting started and in-the-large series, right?

all on the Untangled playlist

I am, very helpful videos!

I am about to truck ahead into video 3.

is using the code snippet feature in here (using the + to the left of the slack input box) the right place to drop in large error messages, or does everyone have to see it? I'm used to using paste type services.

@tony.kay Finally the figwheel-prompt shows, thank you for your advice. The problem is my chrome’s vpn-plugin for sure. Whenever I disconnect that plugin the prompt will show.Thank you.

@eric.shao whew…lucky guess 😉

😄

@macrobartfast You could use a github gist…if you think a small portion of it is sufficient, then putting it in a `` ` block is good

the support ticket feature isn't offering me the ability to walk back... offers 1 frame of 0, or 0 of 0, even after creating a number of to-dos...

standby for error message from chrome.

it could be the code needs some kind of update. No one has touched that code for the better part of a year. Could be it is in need of some update love. The error may help

ah ok

here's the error (sorry for the delay... getting up to speed on using gists for this):

https://gist.github.com/anonymous/1021513945422b8af4f3f147aa9e8e99

what is in your network tab

any errors there?

no errors there

this doesn’t look like an actual problem…it looks like underdocumented “how to use” and poor error handling in our code 🙂

btw, this is just something I'm checking out because it's cool... this is not a priority ;-D

I’m guessing nothing is wrong with the code

I should be focusing on the videos, anyway.

So, when you created a “support ticket” it showed an ID in the js console

it did... http://localhost:3000/support.html?id=4f28eda9-13c8-4fa2-841f-98fda2ff7c0d

when you start the support viewer, you have to supply that ID as a parameter in the URL. yes, that

of course I want to see this totally sweet thing working, but I can wait!

mmmm. is that the right ID?

that sounds like an Om transaction ID

I don’t remember using UUIDs for that

aha... let me get the log entry

[995.238s] [om.next] transacted '[(support-viewer/send-support-request {:comment "yoodle"}) (support/toggle)], #uuid "66227ac9-6894-456e-aa1f-4d012f4b0780"

oh wait…the SERVER log

aha lol

not the JS log

my bad

no, probably my bad, lol

the server will tell you what it created…use THAT ID 🙂

I am laughing at myself in this coffee shop, looking positively crazy

the intentional use-case is the server would send you an email saying “support case such-and-such” with a clickable URL

only the server needs to knwo the ID

though I guess you could tell the user “Case ID #5 was submitted"

The coolest thing about that feature is that it took almost no code to make it happen…the model of Om just makes it possible, essentially for free

it's freaking awesome

by the way, you said exactly what to do in the readme: '...a support ID in the server logs...'

I'm still getting 1 of 0 frames via http://localhost:3000/support.html?id=1006, but I should rebuild and restart everything as that may resolve this

I mean, I've been a bit rambunctious in setting all this up.

yeah, it should work. The error you were seeing was because there was no data in the request…the code was written rather quickly…lots of important things to build. Examples sometimes get the short shrift

so, the error isn’t very useful

but I will be eager to get it working at some point, as it's going to be super sweet to demo it.

it's a great selling point on using the stack for those for whom the other advantages of clj/cljs may be a bit foggy.

but for now, as I said, I'll keep going on the basics, using the videos, which I greatly appreciate.

when you demo it, realize that there is a way to do the VCR with any js app: record the dom deltas at every event. There are even commercial products to do so. The cool thing about our approach is that you have the actual application state…you can actually fix bugs against the figwheel-run support viewer and watch the user’s error disappear from the view they were looking at

See this great article: https://medium.com/adstage-engineering/contextual-debugging-with-om-next-and-untangled-8c168900dba5#.n6s7i7v55

Talk about the ultimate in “error case reproduction"

Just FYI: on SNAPSHOT I just fixed a bug in routing-tree. That function was not shown in the devguide, but I’d added it for easier use, but messed up on its implementation. Should not affect you if you’re using the devguide, but will affect you if you found it and used it.

@baris @darrellesh The develop branch of untangled-ui now has a devcard showing a simple full stack form. It starts out loading multiple things from a server (which have not been augmented with form support). It then lets you click on them from a table display, initializes them into the form support, and let’s you edit. It also demonstrates simple full-stack updates. See form-demo-cards https://github.com/untangled-web/untangled-ui/blob/develop/src/guide/untangled/ui/form_demo_cards.cljs

The main things that are still missing from form support: 1. more documentation/examples 2. more built-in form components (only have text field and dropdown written…oh, and checkbox I think) 3. maybe a built-in “vertical form” render that can generate a full-blown UI for you with some stock look-and-feel as a convenience when you want something that just looks like a standard form. 4. More built-in validations (1) is already decent, but incomplete. (2) and (4) are made to be extensible, so the existing examples are sufficient for any serious user. (3) is a nice-to-have, but most ppl will use it as a placeholder or example for making their own reusable declarative form generators.

If you’re going to use form support “for real”, then I’d suggest becoming a contributor of the things you immediately need in (2) and (4). (3) requires that we finish the UI stuff in general.

@tony.kay for sure about 2 and 4. The current state of the forms component is nearly complete for me, just missing some few things like the capability for file (images) uploads.

I totally agree with you about 3. It's an easy step when the basic ui components are finished. The entire untangled story gets so powerful after that and I'm looking forward to that.

Hi! Just starting out with Untangled/Om Next here, and I’m trying to ascertain best practices from the get-go.. When creating for example a LoginForm-component, is the preferred way to get the values of the subcomponents (eg username/password) through using om.dom, setting :ref’s on those subcomponents and then accessing the values through om.dom/node?

In plain React, the preferred pattern would be to create some local state in the main component, and add onChange-listeners in the subcomponents to update the main component’s state, which would bypass the need for react refs

And most of the docs/tutorials I’ve seen so far are about more advanced topics, regarding the app state and the reconciler etc 🙂

@torkan So, it is different than that. Neither is the answer. The answer is that Om Next/Untangled require you do some understanding up front of the overall model. It may sound “more advanced”, but in fact the overall model makes everything simpler. It does require more learning up front. The Quick Introduction in the Untangled Dev Guide is your best bet

http://untangled-web.github.io/untangled/guide.html

http://untangled-web.github.io/untangled/guide.html#!/untangled_devguide.A_Quick_Tour

@baris File uploads…hoping the image library component helps people see how to build that if the one we supply isn’t enough. We’ll get the docs out on the new modular server support ASAP.

@tony.kay Thanks for replying 🙂 I’ve run through most of the devguide (at least up to section G), so I have the main concepts about the app state pretty much down, I was thinking that this is the sort of use-case where you don’t want to update the app-state on every keypress by the user, and should rather rely on local state

Ah, I see. That is a very common question. Yes, component local state is there, and you can use it if you’re experiencing performance problems with something that updates rapidly.

defui makes a standard React component that can use the complete set of React features

However, I have failed to see an example that handles an input field in that way in your docs, or in Om Next’s, I might have just missed it though 🙂

But, as soon as you break away from the app state, you lose your ability to see those interactions in the support viewer.

Yeah, the reason I don’t want to put it in the app state, is precisely due to this, seeing every state update due to filling in fields are probably not that useful

So, for example, in untangled-ui (not quite officially released yet) there is form state support. That feature would not be nearly as clean if the form data wasn’t being completely managed at the app-state level.

(in the support viewer)

Ah ok, so putting it all in the app-state is the way to go after all then?

We’ve talked about “compressing history” as well, where transacts could be labeled as compressable, and more than one of those in sequence could be elided from the history on support requests.

Also, you cannot visually regression test components if the state isn’t coming through props

they are no longer pure functions

so, I use component local state rarely. One example might be a graphical representation (e.g. drag n drop) where it is just too slow otherwise

Yeah, that would be super-useful… I’ve used both Redux DevTools and Redux-form (which handles all form state through the redux state object)… Redux DevTools has a filter feature that basically allows you the same functionality

so, only give up the benefits of pure rendering when performance won’t let you do anything else

Yeah, these ideas are catching on everywhere. Immutable state and pure rendering rock

Yup, that’s the main reason I decided to build my next project with Untangled, achieving all these concepts comes much more naturally and unforced with cljs/om/untangled, doing it in JS is a lot more cumbersome

What is the current state of untangled-ui? Still relatively safe to start using, even though it’s not officially released yet, or?

So, untangled ui is in a bit of flux as far as the CSS and wrappers go. The forms support isn’t changing (but may have bugs…and is missing stuff as described earlier). The image library works but is undocumented.

It is on clojars in a SNAPSHOT form. I don’t plan to rename things, but argument lists might change slightly or expand.

So, “safe to use” is “yes”, as long as you’re willing to tweak as we go.

for example, we changed our minds on elements/ui-button on friday, and change the arglists and CSS to support more pure semantics so the CSS could be more easily themed and the API could be a bit more natural for the programmer.

The layout responsive grid stuff is solid (but will get richer). The media selector stuff is also solid in layout/rwhen

We’ve removed the inclusion of the generated CSS from Git (as should be the case for generated files). So you have to use the README.css instructions to generate it.

The JAR generation story will include a build of it that will package the default CSS, but that is on the TODO list

mostly we expect people will want to edit the settings and generate app-specific themed CSS

We’re also toying with dropping the external CSS altogether and moving to co-located CSS generated dynamically with the components. Then you’d configure the theme via CLJS variables and we can get rid of all of the crap necessary to make the external CSS.

via this: https://github.com/untangled-web/om-css

Cool! I’ll check it out then 🙂

that’s a bit off in the future, but it would have some cool advantages.

So many things for aspiring OSS contributors to help with 😉

One caveat with the css module approach (at least if you are creating hashed classnames etc), is that you require a full rebuild if you have an app that is to be shipped with various themes

The themes are variable settings that are evaluated at runtime

Could probably be solved with some fancy server-rendering which sets everything up first I guess, I haven’t looked into that stuff yet 🙂

Theming could just update those values and re-emit the CSS to the DOM

not server-side at all

Aah

It just becomes part of your minified JS file

and the CSS would be data, which isn’t rewritten by Closure

Got it… We tried out the module approach for one of our apps at work, it became a little tedious as we have multiple instances of the same app for different customers (with different theming), and we basically have to rebuild everything if we just did some minor css updates

well, depending on the change, this would require you to recompile the app (since the CSS is in the app)

This presupposes that you don’t want to burden the client with a lot of unused css of course 🙂

if it were just color changes/font/spacing, then you could easily use js variables (set in the header before load) to theme and have your cljs read those as the settings

https://github.com/untangled-web/untangled-cookbook/blob/master/recipes/css/src/client/app/ui.cljs#L18

imagine instead of ’blue using something like js/color

the local-kw helper just namespaces the class to the component

Yeah, it’s unfortunately more cumbersome than that, so we ended up with just building separate css-files, and have the deployment-scripts pick a css-file to include in index.html depending on the instance

ah, well, when your requirement complexity exceeds the abilities of your tools...

find a way to convince the sales people/clients of a simpler solution 🙂

Haha yes, the permanent state of any front-end dev 🙂

e.g. do you really need that insignificant tweak to the look that costs twice as much?

well, if you put $$$ to it, a lot of times they’ll agree

“Yes, we can do that, but it’s $$ more"

Usually these are process/people problems. You can only solve those with non-technical means…e.g. track exactly how much it is costing the company, and make that known to the accountants. They’ll want to pass that along via sales, which makes the sales guy want to sell it differently

unfortunately, that usually happens after you’ve already signed contracts that have doomed you to suck-dom

For our situation, it’s that we are one of the biggest universities in the country, and we provide a set of services for both ourselves and a lot of other academic institutions… And all those institutions of course already have a general theming to all their online services, so we have to adhere to them 🙂

Ah. Well, that does make it harder

Yeah, they pay for it though, it’s just that we have to ensure we have a sensible way of serving tailor-made css to all of them, and avoiding the inclusion of all of the irrelevant themes in the builds

But you’re using the BEM-approach so far in untangled-ui, so it’s all good 🙂

Yeah, our CSS guy is pretty good, and we’re trying to make everything easy to augment. Everything allows the addition of your own CSS classes alongside the ones the helpers (like ui-button) add

I’ll try it out, looks good (like the rest of Untangled)!

Thanks. It’s getting there

Speaking of om-css, are there plans to make is available in #?(:clj ..)? Thanks for the dev guide by the way, most approachable resource to learn om 🙂

@nha the library is tiny (126 lines of code). It would take very little time to make it ss rendering compatible. Not using it at the moment. The whole om-css things was more of a side thought that you could easily do without a library, but be glad to take a PR.