[ClojureScript] Re: [ANN] Replete ClojureScript REPL iOS app available
It was approved as is. > Out of curiosity, how painful/painless was the process of getting it accepted > into the app store? I've heard that Apple is pretty sensitive about letting > anything in that does any kind of evaluation of arbitrary code. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] Re: [ANN] Replete ClojureScript REPL iOS app available
On Monday, July 20, 2015 at 4:28:51 PM UTC-5, Mike Fikes wrote: > Replete 1.0 is now in the App Store > > > http://blog.fikesfarm.com/posts/2015-07-20-ios-clojurescript-repl-available-in-app-store.html That's incredibly cool! There don't seem to be many open source apps for the iOS platform, so it is great to have the source for a full-blown app that actually made it into the app store. And one that uses ClojureScript and actually makes a REPL available takes its coolness off the charts. Out of curiosity, how painful/painless was the process of getting it accepted into the app store? I've heard that Apple is pretty sensitive about letting anything in that does any kind of evaluation of arbitrary code. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Client-only Applications
On Friday, July 24, 2015 at 2:00:28 AM UTC-5, Gary Verhaegen wrote: > On Thursday, 23 July 2015, Gary Schiltz wrote: > If I were writing it in Swing for the desktop, I'd create a top level frame, > populate it with a bunch of nested panels to group widgets like buttons, text > fields, text areas, etc, use some layout managers to make it display nicely > when resized, and attach event listeners to the interactive widgets. I could > use seesaw (https://github.com/daveray/seesaw) to write in Clojure instead of > Java to interact with Swing. Is there an equivalent ClojureScript library > that similarly interacts with some JavaScript widget library? > > React/Om works mostly like that, except that you use CSS as your layout > manager. I'm > not too sure about accessing files directly from a webpage, though. There may > be security > restrictions there. > > If you want to do anything with web technologies, you really have to spend > some time learning > HTML and CSS, even if you don't intend to write them yourself. Maybe in the > future there will > be rich enough sets of premade widgets, but my feeling is that at this point > you have to > understand your compilation target. Of course, you're right about the value of knowing web tech when the browser is the target. I wasn't trying to be lazy (well, maybe a little :-), and I'm not completely ignorant of HTML and CSS, just a lot more experienced with desktop development for the client side. I am genuinely interested in what people in the industry use to target complex single page apps, delivered in the browser. And by complex, I am mainly referring to dynamic visual layout, and interaction semantics (i.e. creation, deletion, and modification of widgets to reflect app state). I know that HTML and CSS is the lingua franca of web designers, so when there is a significant involvement by web designers in a project, it makes no sense to try to bypass HTML and CSS. However, just as JavaScript can be thought of as an assembly language for ClojureScript (or CoffeeScript, etc), HTML and CSS can be thought of as assembly languages for hiccup, crate, garden, etc. Anyway, I'm not looking for a philosophical discussion about HTML/CSS/XML vs S-expressions, I was just wondering what folks consider to be the current state of the art for creating complex single page apps (and in my case, client-only apps). My impression is that a lot of what would would be implemented as JPanels in Swing would be div elements in HTML, and Fluxbox (HTML5) or a polyfill for it (HTML 4.1) are used for layout of the div elements and their contents. In the case of very simple widgets, perhaps form elements such as are enough, but in anything more complex, folks use widget sets like JQueryUI, Sencha, etc. What is interesting to me is that where Java on the desktop pretty quickly settled on AWT and Swing (and SWT to an extent) back in the 1990s, there doesn't yet seem to be that much of a consensus on how to do single page apps. Is this also others' perception? Gary S -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] re-frame - idiomatic usage for decorating entities?
>From Slack the answer is _not_ to do: > (defn table-row [_] > (fn [raw-row] >(let [decorated-row (subscribe [:decorated-row (row)] > [:tr [:td (:manager-desc @row)]]))) but rather: > (defn table-row [row] (let [decorated-row (subscribe [:decorated-row (row)] > > (fn [raw-row] > [:tr [:td (:manager-desc @decorated-row)]]))) i.e. the let always goes outside the inner fn otherwise you get one subscription per rendering which isn’t what you want. Thanks Mike and profil > On 24 Jul 2015, at 11:12, Colin Yates wrote: > > Hi, > > I have a table component which iterates a list of entities and calls a row > component passing in that entity. In concrete terms I have a bunch of > 'customers' that contain a FK ID of their manager and I want to render the > name of the manager. > > I need to decorate that entity with other things (resolving names of linked > entities for example) and I can see a number of ways of doing that (hack code > warning): > > [decorate the collection in a sub] > Have a subscription which returns the decorated entities. This subscription > would use other subscriptions to resolve the ids: > > (register-sub :results > (fn [db] >(let [raw-results (subscribe [:raw-results]) > managers (subscribe [:manager/by-id])] > (reaction > (map (fn [row] (assoc row :manager-desc (managers (:manager-id row))) > @raw-results) > > The cost is that this subscription is re-evaluated for every row if either > the raw-results or the manager changes. > > [decorate the collection in the component] > (defn table-rows [] > (let [raw-results (subscribe [:raw-results]) >managers (subscribe [:manager/by-id])] >(fn [] > (let [results (map (fn [row] (assoc row :manager-desc (managers > (:manager-id row))) @raw-results)] >(into [:tbody] (map table-row results))) > > The cost here is that the entire table is re-rendered every time either the > managers or the raw-results change, however the table-row rendering should be > short circuited for the non-changed rows. > > [decorate the collection in an entity-specific subscription] > (register-sub :decorated-row > (fn [db [_ row] >(let [managers (subscribe [:manager/by-id])] > (reaction > (assoc row :manager-desc (managers (:manager-id row)) > > (defn table-row [_] > (fn [raw-row] >(let [decorated-row (subscribe [:decorated-row (row)] > [:tr [:td (:manager-desc @row)]]))) > > (defn table-rows [] > (let [raw-results (subscribe [:raw-results])] >(fn [] >(into [:tbody] (map table-row @raw-results)) > > This feels the cleanest and changes are scoped to as small a change as > possible. > > The fourth variation is the same as above except table-row doesn't delegate > to a subscription rather it subscribes to the managers map and resolves it > inline. > > What do you all consider 'idiomatic' and most performant? > > Thanks! > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescript@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] re-frame - idiomatic usage for decorating entities?
Hi, I have a table component which iterates a list of entities and calls a row component passing in that entity. In concrete terms I have a bunch of 'customers' that contain a FK ID of their manager and I want to render the name of the manager. I need to decorate that entity with other things (resolving names of linked entities for example) and I can see a number of ways of doing that (hack code warning): [decorate the collection in a sub] Have a subscription which returns the decorated entities. This subscription would use other subscriptions to resolve the ids: (register-sub :results (fn [db] (let [raw-results (subscribe [:raw-results]) managers (subscribe [:manager/by-id])] (reaction (map (fn [row] (assoc row :manager-desc (managers (:manager-id row))) @raw-results) The cost is that this subscription is re-evaluated for every row if either the raw-results or the manager changes. [decorate the collection in the component] (defn table-rows [] (let [raw-results (subscribe [:raw-results]) managers (subscribe [:manager/by-id])] (fn [] (let [results (map (fn [row] (assoc row :manager-desc (managers (:manager-id row))) @raw-results)] (into [:tbody] (map table-row results))) The cost here is that the entire table is re-rendered every time either the managers or the raw-results change, however the table-row rendering should be short circuited for the non-changed rows. [decorate the collection in an entity-specific subscription] (register-sub :decorated-row (fn [db [_ row] (let [managers (subscribe [:manager/by-id])] (reaction (assoc row :manager-desc (managers (:manager-id row)) (defn table-row [_] (fn [raw-row] (let [decorated-row (subscribe [:decorated-row (row)] [:tr [:td (:manager-desc @row)]]))) (defn table-rows [] (let [raw-results (subscribe [:raw-results])] (fn [] (into [:tbody] (map table-row @raw-results)) This feels the cleanest and changes are scoped to as small a change as possible. The fourth variation is the same as above except table-row doesn't delegate to a subscription rather it subscribes to the managers map and resolves it inline. What do you all consider 'idiomatic' and most performant? Thanks! -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Exponential compile times on minor edits
In general it is better to read that kind of deeply nested, big structures as EDN at runtime than to compile it directly as part of the code. (This is also true for JVM Clojure.) On Thursday, 23 July 2015, Timothy Pratley wrote: > FYI this is caused by > [:a [:a [:a [:a [:a [:a [:a [:a [:a [:a [:a [:a [:a [:a [:a [:a [:a [:a > [:a [:a [:a [:a]] > which ClojureScript turns into nested data + function calls > -> > https://github.com/google/closure-compiler/issues/1049 > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com . > To post to this group, send email to clojurescript@googlegroups.com > . > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Client-only Applications
On Thursday, 23 July 2015, Gary Schiltz wrote: > > If I were writing it in Swing for the desktop, I'd create a top level > frame, populate it with a bunch of nested panels to group widgets like > buttons, text fields, text areas, etc, use some layout managers to make it > display nicely when resized, and attach event listeners to the interactive > widgets. I could use seesaw (https://github.com/daveray/seesaw) to write > in Clojure instead of Java to interact with Swing. Is there an equivalent > ClojureScript library that similarly interacts with some JavaScript widget > library? > React/Om works mostly like that, except that you use CSS as your layout manager. I'm not too sure about accessing files directly from a webpage, though. There may be security restrictions there. If you want to do anything with web technologies, you really have to spend some time learning HTML and CSS, even if you don't intend to write them yourself. Maybe in the future there will be rich enough sets of premade widgets, but my feeling is that at this point you have to understand your compilation target. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
