Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Matthew Hayden
@mrehayden1
I just accidentally bumped to typescript=3.6.3 and .event from @cycle/dom was causing errors everywhere I used it
John Pallister
@synchromesh
@siassaj @brucou I found Miro Samek's Practical Statecharts in C/C++: Quantum Programming for Embedded Systems to be very good, but that was, goodness, over fifteen years ago now and there might well be better books on the subject...
siassaj
@siassaj
@synchromesh its an interesting topic isnt it
siassaj
@siassaj
@brucou are we allowed to pass event arguments in a formal state machine implementation
i've seen people set data, then fire the event
brucou
@brucou
@siassaj you are allowed to do whatever the specific library you use allow you to do, right? Formally speaking the notion of parametric events (i.e. events with data) seems to come more often with extended state machines.
brucou
@brucou
@siassaj were you referring for example to https://github.com/jakesgordon/javascript-state-machine ? I saw that he has a 3.x newer version with funny stuff, like wildcards, dynamic transitions and other rarities.
siassaj
@siassaj
No I haven’t used any statemachines in JavaScript yet
I did build a bunch of state modelling modules where functions were built in the spirit of event machines, and it worked
But not exactly a state machine so no formalism
siassaj
@siassaj
@brucou yeah just didn't know if event payloads were allowed
if it broke deteriministic behaviour
brucou
@brucou
I don't think they are event payloads in basic state machines, but in extended state machines, there are.
why would it broke deterministic behaviour?
brucou
@brucou

To recenter the subject of state machines on cycle.js, I want to emphasize that a cycle component is f::Sources -> Sinks where Sources is either an event source, or an event source factory, and Sinks are the commands to run. That makes cycle.js quite a natural fit for using state machines, as long as the machine computes commands from events. The component becomes something like

function f(sources){
  const {eventSource$} = sources;
  const commands$ = eventSource.map(fsm);

  return {
    sink1: commands$.map(extractSink1Command).filter(Boolean)
    ...
  }
}

where extractSink1Command:: Command -> Maybe Sink1Command, and commands$:: Stream Command

brucou
@brucou

In practice, your machine will take several event sources, so const commands$ = eventSource.map(fsm); may become const commands$ = merge(eventSource1, eventSource2, ...).map(fsm)

When you do it like this, there is no need to handler reducers, use isolation etc. The machine already handles the necessary state in an isolated way. That may or may not have better ergonomics according to the taste du jour. But for complex logic, I really think that it is a pretty attractive option.

This message was deleted
Marton Sari
@sarimarton
One thing I find myself frequently using is .compose(dropRepeats()). With combine's and merge's and map's, stream event propagations can easily go out of hand, and then at some point you have to control and clean it up with this. Maybe this is another phenomenon which belongs to the UI characteristics. I think dropRepeats could be a default behavior with MemoryStreams
Marton Sari
@sarimarton
or some default somewhere :D
Tim Wisniewski
@timwis
Hiya all! I've been reading through the cycle js guide over the past week and have been excited to check it out. But I tried to get started this afternoon using create-cycle-app one fits all, and felt quite overwhelmed by the boilerplate it created! Lots of imports I don't recognise, and concepts the guide didn't cover... I found myself deciding to try another new framework for my app. But thought I'd share here first in case anyone has experienced this before. I was excited to try FRP in practise
For context, I've read many tutorials on functional programming, built a basic app in elixir, dabbled with elm (mostly the tutorial), used regular streams in node, and have built many apps in Vue and react. Just thought at least you might appreciate feedback from a "beginner"
Marton Sari
@sarimarton
@timwis 1. Code generators suck 2. Cycle is best used as a barebone base. It has no VDOM componentization. You have to build your ergonomy around it, or look around at https://github.com/cyclejs-community/awesome-cyclejs
brucou
@brucou
mmm to be fair, I have a much better experience with create-cycle-app and I find it pretty useful but then I already knew about cycle before cycle-create-app came to be, so maybe there are specific points that are not beginner friendly?

@timwis what could useful and actionable feedback would be to precisely indicate your stumbling blocks.

concepts the guide didn't cover

Which concepts are those? Which guide are you following?

imports I don't recognise

which are those?

I understand how frustrating it is to feel blocked with build/boilerplate/etc before even having started to write an application. With that in mind, if you ask concrete questions about the precise problems you are experiencing, you may be able to find help here.

In any case, it is great that you have taken the time to try cycle and give feedback here.

Tim Wisniewski
@timwis
@brucou I went through and wrote down the bits that were unfamiliar after reading the guide (https://cycle.js.org/getting-started.html through 'Components')
Overall, I think routing is the biggest shock. The guide doesn't cover that, it uses multiple libs (including one outside the @cycle scope), and it's referenced in several files rather than just contained in one place (in fact much of the boilerplate seems to be for routing). Perhaps an additional page in the guide for how routing works would be a good bridge?
Tim Wisniewski
@timwis
Beyond that, the drivers.ts file is just doing a couple things that I don't understand why they're necessary. For instance, in the guide, the drivers object is always just a simple object. In this everything's wrapped in a function, and there's a whole function just to execute each function, and then we're computing the driver names but omitting one of them and adding in two others for some reason. And there's several imports that weren't in the guide (withState, routerify, switchPath) which I can mostly infer but still had to lookup their readmes to get what's going on
I wish I could also provide suggestions for improvements! All I've got for now is adding a page on routing to the guide (maybe introducing withState as well?). I hope my feedback is constructive. I can imagine it's hard to find the right balance between something accessible to beginners and something useful for regular users.
IMO vue's cli finds that balance really well with its plugin ecosystem (you're asked whether you want to include a router and central state management as part of the install prompts, optionally adding additional plugins later and there's no need to ever eject) though that was a big undertaking
Marton Sari
@sarimarton
Routing is something I'd say cycle's architecture just shines in, and additional libraries just add confusion, complexity and noise. You don't need any lib for that, it's just a url channel on the history driver - https://codesandbox.io/s/github/sarimarton/tmdb-ui-powercycle
siassaj
@siassaj
I think the cycle router is reasonable
@timwis so the thing about cycles drivers is that they are all rather different from one another. Further, some functionality uses wrappers rather than drivers (such as when there is no actual IO)
brucou
@brucou
@jvanbruegge Hope you are doing good with the thesis. A quick question. @timwis made some comments (above this post) about the documentation. I believe there is an issue where this is already tracked. The idea would be to include this feedback there, so it is not lost in a sea of messages and can be retrieved when you guys are getting back to work on the doc. Do you know what that issue would be ?
Jan van Brügge
@jvanbruegge
yeah, thesis is much work, but i am getting there
this is the issue with the current plan: cyclejs/cyclejs#851
brucou
@brucou
@jvanbruegge best of luck with that.
@timwis have a look at the issue mentioned by @jvanbruegge , I pasted your comment there (https://github.com/cyclejs/cyclejs/issues/851#issuecomment-534685080)
There is an ongoing effort to improve the documentation. I think routing is a part of that, as I see the driver @cycle/history being used there. I certainly agree that routing should be documented specifically as this seems to be a common enough request.
brucou
@brucou
About routing specifically, I can think of three ways to do this:
  1. Your routes are cycle components, and you manually wired them (that involves listening on route changes and computing new sinks when the route changes)
  2. You use the wrapper/driver (cyclic-router, etc.) that you mentioned above
There are probably more. You can find an example of the first approach in this HackerNews clone: https://github.com/usm4n/cycle-hn/blob/master/src/app.tsx
仄仄
@ppzzppz
don't support cdn ?
brucou
@brucou
works on my machine
Géraud Henrion
@fuunnx
brucou
@brucou
ah true
Nathan
@nspaeth
I need to get info about how a dom element was rendered in order to compute something. What is the best way to do this?
Specifically, I have a css grid that is auto sized to fit its contents, and elements are auto-filled into it. Given an item that is in the grid, I need to find which column it is in so that I can find the next column.
Géraud Henrion
@fuunnx

there is DOM.select('querySelector').element() and DOM.select('querySelector').elements() which return a stream of element and elements matching the selector.

You should be able to find the children and siblings of these DOM elements once you have them

Also there are snabbdom hooks that give access to the "rendered" dom element https://github.com/snabbdom/snabbdom#usage

Nathan
@nspaeth
@fuunnx Thanks.
brucou
@brucou
@sarimarton (yet another) UI library, but this one mixes observables into views, like you do. Only does the view part though, no componentization but simple functions would do the trick if the component keeps to simple UI rendering. https://sinuous.netlify.com/