Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Nathan
@nspaeth
(Or tallbags?)
Gil
@sendtogil
you can make callbags work with xstream
Nathan
@nspaeth
Yeah, I'm just wondering how the internals are going to change.
André Staltz
@staltz
The internals are going to change, that's what we can promise. I think at this point it's better if we just focus on building, not taking
*talking
Jan van Brügge
@jvanbruegge
but to answer the question, no xstream will not be rewritten to use callbags, cycle just wont depend on xstream any more, but you can still use it in your application code
André Staltz
@staltz
Yes
siassaj
@siassaj
yay
my visualizer became irrelevant
Jan van Brügge
@jvanbruegge
i dont think so, you were visualizing the app only anyways
siassaj
@siassaj
property based tests are nuts
siassaj
@siassaj
ltl eh
ltl is abit like statemachines eh?
although there's no idea of a tagged state
is it like a rule based ordering of operations?
kind of like a more structured & constrained composotion of functions
Jason Awbrey
@jsonberry
Cool to hear about the next version of cycle, sounds interesting!
Would you expect major breaking changes to the current API?
@jvanbruegge @staltz :point_up:
Jan van Brügge
@jvanbruegge
depends on what you call major, but in my opinion no, nothing major. Of course there will be some breaking changes, but it should be easy to fix them, the general principle of Cycle.js does not change and most of the new stuff is in run
André Staltz
@staltz

I'd say the biggest change is in how drivers will be written. it will most likely be an object shape (in TypeScript: interface; in JavaScript: any object with these methods)

{
  consume(sink) // returns subscription
  produce() // returns source
}

Instead of functions-as-drivers: function driver(sink): source

and the internal "engine" in cycle.js will be callbags, not xstream. but we'll support xstream/rxjs/most
PEZO
@ZoliPeto_twitter

Hi all! Nice to be here!

@staltz I am not an expert, but I am really interested in a verifiable systems. Note I learned about LTL/CTL just by myself. “Plain” LTL feels a bit too restrictive and CTL has the state explosion problem. The only ways (I am aware of) to omit/cure/restrict the problems of the state explosion (and CTL) are “proofs” and “values as types”.

I am wondering if Advanced Types in Typescript ( https://www.typescriptlang.org/docs/handbook/advanced-types.html) are useful enough (my intuition says yes) to overcome these problems (the code might be really unusual though with “type"/"values as types" magic going on), Typescript has truly Dependently Typed (but maybe limited?) features (check this Eric Meijer tweet: “...all the advanced dependent types features..." https://twitter.com/headinthebox/status/997499854321405953?lang=en).
Dependent Types ~= “values as types” and enable the compiler to check a lot of things (like proofs).

XState recently added Typestates ( https://xstate.js.org/docs/guides/typescript.html#typestates ) , I think there might be a lot of things to learn from about narrowing the states in the state explosion.

I think it might be also useful to check a bit of Idris (if you have some time and are full of Rust :) ). http://docs.idris-lang.org/en/latest/tutorial/introduction.html
To me, these two sentences are really important for understanding the necessity of the building blocks of Idris, especially the second: "This tutorial introduces Idris, a general purpose functional programming language with dependent types. The goal of the Idris project is to build a dependently typed language suitable for verifiable general purpose programming.”

My intuition says the same way Cycle and it's architecture is above other frameworks like React, when it comes to testing and verification dependently types and proofs are just crucial, unavoidable and above anything else (normal, not dependently typed type systems).

Cycle is the only framework of todays I am aware of which can go gradually mainstream considering the ecosystem, jobs, etc. and the only one which has the “right, high level of abstraction” so could profit from these dependent typed based test improvements (via Typescript). I’ve checked, but not totally sure about Idris / Haskell / Liquid Haskell / Agda / Clojure / Scala (other reactive frameworks) etc., but I haven’t seen many people claiming they have cool, cycle level integration with React Native or any decent, proven way to create ios/android apps, etc.
Compared to their position, and even it is own: Cycle really seems to me unique and if typescript is good enough, it does not need much left to reach the “general purpose, verifiable archicture with an awesome ecosystem and accessibility” - which is like “Complete” to me. So I’m really curious and interested in the limits there can be done via testing and dependent types.

Jan van Brügge
@jvanbruegge
sadly typescript has not true dependent types yet. It has some features that can emulate parts, but in the end you always run into a wall. Also other missing features like higher kinded types really put a dent in the usefulness of typescript. Also the syntax at least feels very ad-hoc. The prime identification of dependent types, using values transparently on the type level is missing completely. Also general purpose computation on the type level. At the moment you can only do mapping of types with a special syntax. This is why you can't even emulate all of dependent types (unlike Haskell for example)
PEZO
@ZoliPeto_twitter
Thanks for the clarification.
siassaj
@siassaj
all of what @jvanbruegge said being true, in a very 'get it fucking done' kind of way typescript is working well for us
there are times when I want to do some nice stuff & not cast, and it can get tough
siassaj
@siassaj
i haven't found an example of an implementation of LTL that I can understand
I gladly answer questions here
Nathan
@nspaeth
@jvanbruegge Are you guys planning on updating the github projects page, or creating a tracking issue? That makes it much easier to follow development, and will help us all know where we can lend a hand. I know that might be a lot of work, so if you guys would rather just work on the code that is understandable.
Jan van Brügge
@jvanbruegge
yeah, a high level overview at least should be manageable
Matthew Hayden
@mrehayden1
more of a snabbdom question, but I'm trying to override the snabbdom modules and it's not working according to the documentation (using @cycle/dom 22.3).
Jan van Brügge
@jvanbruegge
what did not work?
Matthew Hayden
@mrehayden1
@jvanbruegge It was fine, worked it out in the end, user error.
χ
@xiphiness
getting cannot read property map of undefined when using makeHTTPDriver()
wondering why that is? pretty sure my usage is entirely correct
it's like for some reason the driver is being prematurely called without a stream being passed as the sink
χ
@xiphiness
ahh nvm using driver factory paradigm, needed to wrap it in an anon function
Ionut Achim
@monojack
is it normal for sources.DOM.select(selector).element() to emit with every “update” that happens anywhere
Jan van Brügge
@jvanbruegge
anywhere in the subtree, yes
Ionut Achim
@monojack
so, for makeDOMDriver('#root’) - sources.DOM.select(‘#root’).element() would always emit?
Jan van Brügge
@jvanbruegge
yes
at least AFAIK
Ionut Achim
@monojack
hmm.. is there a recommended way to sort a Collection? I’m trying to do it inside a state lens, but it doesn’t sort until there’s a state update
function Lens(sources) {
  const Items = makeCollection({
    //...
  })
}

function View(sources) {
  const { DOM: filtersDOM$, sort$ } = Filters(sources)
  // keep the sorting direction in the app state
  const sortReducer$ = sort$.mapTo(1).fold((acc, x) => acc + x, 1).map(c => (c % 3) - 1).map(sort => state => ({ …state, sort })).  // sort => -1 / 0 / 1

  // state lens for a List component that will render our collection
  const listStateLens = {
    get(state) { 
      if(state.sort) {
        return state.items
      }
      return […state.items].sort( /* …  */)
    } 
  }

  const { DOM: listDOM$ } = isolate(List, {
      state: listStateLens,
    })(sources)

  return { DOM: xs.combine(filtersDOM$, listDOM$) }
}
the above implementation doesn’t sort the list until the next state.items update
Ionut Achim
@monojack
The sort button is not rendered inside Lens but in a different component which shares the same parent with Lens
Kevin
@venikx
I'm curious if it's already possible to SSG cycle.js and if not, would people find it useful?
Géraud Henrion
@fuunnx
what do you mean by SSG ?