Fork me on GitHub

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


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

$> lein do clean, repl
and went to localhost:2345/dev.html


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


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


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


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


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


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


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] [] transacted '[(support-viewer/send-support-request {:comment "yoodle"}) (support/toggle)], #uuid "66227ac9-6894-456e-aa1f-4d012f4b0780"


oh wait…the SERVER log


not the JS log


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


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


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


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


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


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


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.