@mccraigmccraig @petrus even though that document is marked as "experimental"., that approach has been working pretty well for us. It certainly delivers a lot of flexibility.

@mikethompson: yeah, the fact that the queries share the sub's lifecycle seems to take away a lot of complexity... how do you do "loading" indicators though ?

We make our query mechanism return (reactively) a triple of values:

{ :connected  true  
  :query-status  :waiting
  :query-result  []
}

The first two just say "how are things going". The final one is the real result of the query (which is initially nil)

yep, gotit. i think i am converted

Then the GUI sees the :waiting it has the option to put up a "Loading..."

If ever the :connected (web-socket status ??) goes to false then we can show "Dear User, you are offline".

Etc

i've been doing loading indicators from app-db, but this is much better

Just to be clear, this is kinda from app-db

Further explanation: 1. The query mechanism has a query result callback 2. The value given to this callback is the triple described above 3. This callback dispatches this data to a handler which knows how to splice that data into app-db, including the :query-status which causes "Loading..."

(warning - it's early here and i am on zero coffees - i may not be thinking clearly 😫 )

🙂

ok - so the app-db entry will have the same schema as the map above, but the sub will alter the :connected and :query-status keys returned to reflect a query in-flight ?

Yep

app-db is the local source of truth. But data is flowing into it (conceptually from the database).

app-db is kinda like an intermediate node in a Signal graph which is rooted in the database.

dyu mean the back-end database there ?

I have to head off to watch a VERY important game of football

Sorry, yes, backend database

american or original type football ?

Rugby

ah, much better

thanks for the explanation @mikethompson 😄

np .. I;ll be interested to hear how you go

really digging http://metametadata.github.io/carry/user-guide/#basics

This probably gets asked quite often, but does Reagent have server-side rendering? There's reagent.core/render-to-string, which sounds like it could be used for that

I think Yogthos wrote a blogpost about that. Seems like it's quite simple using reader conditionals.

https://yogthos.net/posts/2015-11-24-Serverside-Reagent.html

I don't think he really got it to work though: "React is fairly picky about the structure and the data-reactid tags. So, it can be tricky to generate a DOM tree that it likes. The example in the post will give a React warning about the DOM being different. Some more work is needed around this."

If he's talking about the warning I think he's talking about, it basically means that he lost out on some benefits of server-side rendering

It doesn’t work. Have tried smth like this: (defn ons-toolbar (r/adapt-react-class (. js/Ons -Toolbar))) There seem to be no react classes defined by react-onsenui. But there are elements such as js/OnsToolbarElement. Any input on how to use this to create a react class? Or other ways?

Maybe I'll just have to give it a try myself. I'll honestly be quite surprised if it's terribly difficult to setup, seems quite straight forward. I believe the only thing you need is to have matching react-ids on your DOM elements

And if it actually works, it will definitely have to be mentioned in the README. To many people server-side rendering of React was/is one of its main selling points

Not really in the clojure world, but still 🙂

@luposlip: defn vs def?

@pesterhazy: perhaps. If I define it like this: (def ons-toolbar (r/adapt-react-class (. js/Ons -Toolbar))), and use it like this in a hiccup form: [ons-toolbar], I get this in my console:

template.js:395 Uncaught Error: Assert failed: Invalid Hiccup form: [nil] (in app > view)
(valid-tag? tag)

Seems like there is no such thing as (. js/Ons -Toolbar)

check what -Toolbar is returning

it's probably nil

It returns nil

I can get js/OnsToolbarElement though

then look at its keys, (js/Object.keys js/OnsToolbarElement)

#js []

js/OnsToolbarElement -> #object[ons-toolbar "function ons-toolbar() { [native code] }”]

(js/OnsToolbarElement) -> #object[TypeError TypeError: DOM object constructor cannot be called as a function.]

So I’m thinking perhaps the js/OnsToolbarElement can somehow be wrapped with r/create-element or such. Just didn’t succeed when I tried.

@luposlip: or maybe you need require components from lib. Just see how it do in js, and wrap in is adopt-react-class

perhaps you’re right @savelichalex. I’ve looked into this page: https://onsen.io/v2/docs/guide/react/ And I load .js files with the <script/> tags as described. But not with require(…). I do have an Ons object from within my console though, so thought everything had loaded alright.

In their example they basically use their react-elements like this:

var App = React.createClass({
      handleClick: function() {
        ons.notification.alert('Hello world!');
      },

      render: function() {
        return (
          <Ons.Page>
            <Ons.Button onClick={this.handleClick}>Tap me!</Ons.Button>
          </Ons.Page>
        );
      }
    });
    ReactDOM.render(<App />, document.getElementById('app'));

Try to use (def Ons (js/require «<ons-library>»))

Of course you can use script tag

However you need to know variable to call Ons

If library designed for this

Did (var Ons2 (goog.require 'react-onsenui’)), Ons2 is nil afterwards.

gotta go for a while, will come back later. Thanks for your efforts for now.

I think that goog.require not work in this case, because this is for Google Closure namespaces. If you use library from npm use js/require

heya guys, I’m wondering if anyone has thought through the most effective way to debounce something in reframe?

i’m curious if its smarter to do it at the view level - prevent a message from dispatching entirely, or if its wiser to use some temp key in app-db to track the debounciness

both sides present challenges, so i’m wondering if someone already solved this problem

Without knowing too much about what you are doing, I think I'd debounce in an event handler. For example, when the dispatch is handled for this bursty event, look at a time stamp for the last value put into app-db (you have to add both a value and a timestamp), and if this timestamp, is less than some delta from now, just drop the new event on the floor. Or something.

Ie. I'd debounce by stopping excessive writes into app-db, Rather than doing those writes and then trying somehow to stop the view from updating.

Remember that rerenders only happen each annimation frame. So there is a natural debounce to 16ms.

@lwhorton: have you had a look at debouncer function in google closure library: https://google.github.io/closure-library/api/namespace_goog_functions.html#debounce

hello

I seem to be doing something wrong. my :on-click handlers aren't firing, and I can't seem to type in any <input> boxes

@jcromartie: can you show code snippet?

sure

here's the whole thing https://gist.github.com/jcromartie/6a938897679ff25b8fe47143a1dcfce4

O'

I've updated the gist to remove some redundant stuff

specifically, when I click into an input box, and type anything, the caret moves to the end and nothing changes

hm, actually, the on-click is firing

but the change to the atom doesn't change the rest of the app

oh, I should read the warnings

react.inc.js:19368Warning: Failed form propType: You provided a value prop to a form field without an onChange handler. This will render a read-only field. If the field should be mutable use defaultValue. Otherwise, set either onChange or readOnly. Check the render method of ReagentInput.

@jcromartie: i think it needs to be :onClick and not :on-click

it's :on-click according to the Reagent home page

hmm...

http://reagent-project.github.io/

right. sorry about that

also are selected-app and selected-profile meant to be clojurescript atoms and not reagent atoms?

d'oh

of course

I should set up my ns to replace atom with reagent atom

@jcromartie: unfortunately, not able to help. A few things to note - getting warning from the use of for without supplying a ^{:key <id>}, and your input fields do not have on-change event handlers. Seems like are you wanting to be able to edit the key itself, such as foo which will make tracking its value, which starts off as bar a little tricky unless you make a copy. Id recommend starting off smaller, and particularly consolidating your reagent atoms into one. I find it makes reasoning about app-state a bit easier.

yeah I think having one app state atom would be better

and as for the key renaming bit... yeah I agree, maybe I'll convert it to a vector of name value pairs so they maintain order

then I can give them ids with the index

and I can update the app state based on the index

😛

thanks!

np

OMFG

I'm getting the hang of it.

I'm NEVER. GOING. BACKKKKKKKKKKKK

@savelichalex: I don't have js/require?

@luposlip: how do you mean?

js/require return nil. Not a function or object (sorry for the missing markup, writing from my phone)

@luposlip: this is looks strange to me) guess you have wrong name of package in js/require

No, the vanilla js/require is undefined 😉 if I write js/Ons it returns something.