This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-11-08
Channels
- # 100-days-of-code (1)
- # admin-announcements (1)
- # aleph (1)
- # announcements (9)
- # beginners (125)
- # cider (1)
- # cljs-dev (80)
- # cljsrn (2)
- # clojure (82)
- # clojure-czech (1)
- # clojure-dev (5)
- # clojure-finland (1)
- # clojure-italy (16)
- # clojure-nl (6)
- # clojure-spec (24)
- # clojure-uk (39)
- # clojurescript (35)
- # community-development (49)
- # core-async (3)
- # cursive (31)
- # data-science (17)
- # datomic (21)
- # emacs (5)
- # fulcro (92)
- # graphql (1)
- # jobs (2)
- # lambdaisland (1)
- # leiningen (19)
- # luminus (9)
- # off-topic (21)
- # parinfer (6)
- # pedestal (1)
- # portkey (2)
- # re-frame (12)
- # reagent (8)
- # reitit (4)
- # shadow-cljs (117)
- # spacemacs (5)
- # specter (4)
- # sql (2)
- # testing (2)
- # tools-deps (3)
- # vim (1)
a couple of re-frame design questions. I'm implementing a Z-machine, an interpreter for text adventure games, mostly as a learning exercise. I want to write a Gameboy emulator too, partly because I've long wanted to do that, and partly because it would be an interesting performance showcase for CLJS, assuming it's non-terrible.
(1) the Z-machine's view is a stream of text paragraphs, essentially. I want to do infinite scrollback, and not have it re-render old paragraphs of text.
how should I go about rendering that in Reagent without risking whole-document re-rendering?
and (2) the Z-machine is either waiting for a single keystroke, waiting for a line of text, or running opcodes. in that last state, I want to give it a kick every frame, running 100 opcodes and returning a [z-machine new-state]
pair. is there a doc on how to do that kind of each-frame polling?
@braden.shepherdson I don’t know I have a good answer for (1) (although I there maybe some stuff to search for online about “infinite scroll” in React that could help)
for (2) I don’t know that it solves your problem fully, but do you know about :dispatch-later
?
I did not, hm.
it's also entirely possible that the regular queuing behavior of dispatch
would work. that is, I can write a side-effecting event handler that (a) runs the Z-machine a bunch, (b) dispatches the right things based on its final state. and then those newly dispatched events get handled next frame, not synchronously.
unlike a Gameboy, the timing isn't important, it just needs to not hog the CPU.
well, perhaps it's best here to simply be naive and see if I get good behavior out of the box.
for (1) and (2), actually.
@braden.shepherdson For a totally naive way of solving (1), you could store you entire text history as a vector and have your subscription return something like (take-last 10 text-lines)
or use subvec
to have a scrolling window
@braden.shepherdson “cpu hogging” reminded me of https://github.com/Day8/re-frame/blob/master/docs/Solve-the-CPU-hog-problem.md - which perhaps has some usefulness to you if you haven’t read it