This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # beginners (7)
- # boot (30)
- # clara (1)
- # cljs-dev (3)
- # clojure (57)
- # clojure-austin (2)
- # clojure-conj (3)
- # clojure-dev (11)
- # clojure-russia (84)
- # clojurescript (105)
- # data-science (1)
- # devcards (1)
- # editors (4)
- # editors-rus (2)
- # hoplon (119)
- # immutant (1)
- # lein-figwheel (5)
- # off-topic (4)
- # om (6)
- # re-frame (75)
- # reagent (5)
it was not a critique of the change, just an example of the cost of a change, to argue against "light heartedly" introducing capabilities, like this simpler get "syntax"
@onetom: sure, all of that makes sense. I’ve written enough documentation/helper functions that have been equally abused and ignored enough to understand the reluctance
deliberately restricting common programming techniques in a particular domain, like “building a DOM for presenting our data” comes with it’s own set of frustrations
@micha: i’d be interested to hear about how this code path affected performance - I wouldn’t have expected that
@onetom: I had a different experience upgrading 8 app and 2 libs to hoplon 6, only some global find/replaces and I was good to go. But part of the code was already using the
:click notation that was valid on hoplon 5 also.
so we can maintain backwards compatibility at the expense of not performing some optimization
@micha: I really like the ember way of only removing deprecated stuff on majors and adding new things on minors. Sounds pretty sane.
But I did most of the upgrading, once you know what you are doing is simple, but should be a nightmare for people that don't and things break and you have no idea of what is happening.
@mynomoto: yes, we did at least do that :simple_smile: but even on major versions if we can have a flag to enable deprecated features i think it would be good to do it
well i did one of the projects myself to in about an hour just to confirm there is no major issue behind the transition
I was on vacation this last week trying to keep my hands of the computer until monday but I didn't succeed and did https://github.com/mynomoto/flux-challenge/tree/hoplon-solution/submissions/mynomoto
but u know when im coding and helping out to fix mysterious situations some of my colleagues refer to my activity as black magic as they are watching me solving the problems
and i would say not because im a super fckin uber hacker, though quite experienced indeed...
@micha: but there is functionality being added on hoplon 6, this makes the transition harder. It's not only a matter of not using deprecated stuff, there was mandatory changes. But it is hard to do like them, it is just a thought.
@micha: it is, so if you are not using anything deprecated, you can bump the major and it's gold.
@micha: haha, glad to help once in a while. I own a lot to the people in this channel but mainly you.
I saw that, I just use cells for that problem. I'm not convinced that those are necessary. Cells are amazing :wink:
one thing i found myself using something like that for was like when you have "false" elements
like with the google maps component we have now, you configure it by setting attributes to cells that contain data
and the component knows how to transform that data into domain specific things, like pins on the map or polygons etc
you'd want that if you were styling the pins or something and you want to use the already familiar element abstraction even for data
we were trying to integrate the structure our designer provided with as little alteration as possible
I understand the argument of familiar abstractions but I like data as maps and vectors. But to integrate on an existing project or flow may be useful, but it looks complex.
i made the boxed type so that you can add it as a child, which is really an implementation detail
Hum, that I like. Just ignoring non renderable things. I remember having problems adding cells where they shouldn't be.
Oh, you need to go to the server folder on the toplevel and do
npm install then
index.html.js on my submission toplevel are required by the challenge too.
"Do not make any request for a sith that would be outside the list. Cancel any such obsolete request when the user scrolls."
You are scrolling up, some request is happening, you scroll down and now it wouldn't be rendered.
(brilliant - one browser window was talking about the new star wars trailer, the other window had @micha talking about ‘do not make any request for a sith’ :-))
oh i see, like you scroll up and it's going to fetch two things, and you scroll down before it finishes fetching the bottom two things it should cancel the outstanding requests because they would be out of view
I just suppose that up and down are opposite directions. When I use a mac the first thing I do is invert the scroll :stuck_out_tongue:
Cool. I used one 3840 x 2160 27'' that was amazing at work. Need to find me one of those for home.
Oh, I remembered a problem that I had updating an app. Did something change on
:toggle? It hides things ok but when it shows it is using
display: block all the time breaking
td. I'm setting the display manually but I'm sure this used to work using
@mynomoto: cool, re: flux challenge! be curious to know how you feel hoplon compares
@alandipert I think your orodev talk killed it. Hoplon is simpler and unless you get to the point of having performance troubles (which I never did) I recommend people to stick to it. From what I saw of the other solutions people are really smart so they don't mind the complexity :wink:
@alandipert: reagent is not bad also, the solution over there is nice too using re-frame. It's the most hoplon like react wrapper on clojurescript.