Hi guys! I am very new to cyclejs, can someone please guide me on how should I go about making a I/O websocket driver.
Hi, Aditya. I'm new to this Gitter community, but I've been using Cycle.js off-and-on for a few years.
Have you had a chance to read these?
cyclejs/cyclejs#645
https://cycle.js.org/drivers.html#drivers-how-to-make-drivers
If you scroll down the second link, there's a function WSDriver(/* no sinks */) {…} example.
You mention being new to Cycle.js; have you tried out the basic examples first?
@allen4atsi: I've read the documentation and understood the basics, the app on which I am working is using rxjs and there are no examples with that in the documentation, but I am working my way through it. The main issue is with the websocket(read and write), is there any elaborate code of the same?
2 replies
Oh I hope that is possible. btw I am trying to integrate them I'll share the code if it's done :) Thanks!
I'm trying to use the Google Sheets API as both an output and input to Cycle's main. My first instinct is that it could be a driver, but I haven't come up with a great pattern to model it after. I don't really need it to do everything that the Sheets API does, so it doesn't make much sense to put in a message for everything; but the docs recommend not putting business logic in the drivers, so I don't necessarily want to just send string messages which do a business-specific function. And the docs also say that there's not usually a need to make a driver unless exposing it as a library.
So... what's the best way to encapsulate this type of interaction? Is a driver the right way to go, or is there something better? And if so, what's a good model for a rather diverse API?
Hi @allen4atsi , good job with your app if you managed to make it work
for collections, the first thing that comes to my mind is that you can use maleCollection from cycle/state : https://cycle.js.org/api/state.html#cycle-state-source-usage-how-to-handle-a-dynamic-list-of-nested-components
for collections, the first thing that comes to my mind is that you can use maleCollection from cycle/state : https://cycle.js.org/api/state.html#cycle-state-source-usage-how-to-handle-a-dynamic-list-of-nested-components
@geppettodivacin I don't know the sheets api, but if it's an sdk, a driver is probably the way to go
sources to read values, sinks to update the sheet
Login/logout, read a sheet, and update a sheet
Is that three different streams? Or one stream with a discriminator value?
I guess in the end that doesn't matter much.
What I ended up going with was making a driver that just takes functions as input, so it can be really general. Maybe it's too general but it's a small project.
Thank you @fuunnx ! Like everything Cycle.js so far, seems like it will be a lot to wrap my brain around, but powerful once I get the hang of it. 🙂 Also, my little testing project so far only adds new components; does not handle removing them yet, so
makeCollection definitely seems to be the way to go (from your link: "pickMerge and pickCombine …operate on a dynamic (growing or shrinking) collection of children instances.").
I haven't gotten around to trying out makeCollection yet, but I did add a fun branch in my little train-simulator-game that shows where I want to go eventually: animation in an SVG.
I'm pretty sure my current approach using xs.periodic() is too naïve (and definitely the whole first commit on this branch is hastily written as just a proof-of-concept), but I like my little overlapping squares and wanted to share. :)
I decided to make my driver a little more robust than just "take an arbitrary function as input..." didn't really seem like it fit the paradigm well. But I'm having trouble figuring out how to make a driver with multiple streams. I get how to make a driver that's just one stream, but making one with multiple like DOM... I'm getting errors.
Uncaught TypeError: this.ins.subscribe is not a function
_start index.ts:137
_add index.ts:1150
addListener index.ts:1210
subscribe index.ts:1230
subscriptions internals.ts:98
replicateMany internals.ts:97
_run index.ts:160
_run index.ts:97
run index.ts:207
<anonymous> main.ts:37
index.ts:137:25
_start index.ts:137
_add index.ts:1150
addListener index.ts:1210
subscribe index.ts:1230
subscriptions internals.ts:98
map self-hosted:224
replicateMany internals.ts:97
_run index.ts:160
_run index.ts:97
run index.ts:207
<anonymous> main.ts:37
InnerModuleEvaluation self-hosted:2374
evaluation self-hosted:2335
What are the requirements of a driver type? I know it's a function that returns something but I don't know what that something has to have.
Here's my starting point:
class GoogleDriver {
private _responses: Stream<any> | null = null;
private _loginChanges: Stream<any> | null = null;
constructor(private stream: Stream<GoogleInput>) {
}
responses() {
if (this._responses === null)
this._responses = adapt(xs.create(new GoogleResponder(this.stream)))
return this._responses;
}
loginChanges() {
if (this._loginChanges === null)
this._loginChanges = adapt(xs.create({
start: listener =>
makeUpdateSigninStatus(listener),
stop: () => {}
}));
return this._loginChanges;
}
}GoogleResponder is a Producer<any>.
I have some existing code that I am updating to be better typed. In doing so I've run into some confusion on my end. I have a component that uses a scoped
isolate with with an object scope where one of the keys is a lens. I can't find any documentation about that usage in the scope documentation. When trying to merge streams from that isolated component I am running into an issue with the types not matching.
My code looks approximately like:
export interface IDesktopState {
count: number // canary
windows: IWindow[]
search: string
}
const filterWindows =
pipe<[IDesktopState], IWindow[], IWindow[], IWindow[]>(
prop('windows'),
filter(windowHasTabManagerTab),
filter(windowHasTabs)
)
export const searchLens: Lens<IDesktopState, IWindow[]> = {
get: filterWindows,
set: (state: IDesktopState, _childState: IWindow[]) => state, // Read-only view: just ignore changes
}
export type DesktopReducer = Reducer<IDesktopState>
export type DesktopSources = IDriverSources & { state: StateSource<IDesktopState> }
export type DesktopSinks = DriverSinks & { state: Stream<DesktopReducer> }
export function Home(sources: DesktopSources): DesktopSinks {
const isolateDesktop$ = isolate(Desktop, { state: searchLens, DOM: '.home' }) as Component<DesktopSources, WindowSinks>
const desktop$ = isolateDesktop$(sources)
const ownIntent$ = intent(sources.DOM)
return {
//...
state: xs.merge(ownIntent$.state, desktop$.state)
}
}
The problem is that
desktop$'s state is type IWindow[], and in the outer scope puts that under the windows property, so it is attempting to merge the window list into the object, which isn't correct. What is the best way to handle this? Should I wrap the state in the merge, like: state: xs.merge(ownIntent$.state, { windows: desktop$.state }), or is there some way to get the lens to automatically map that back?
Or, maybe there is some better way to accomplish what I am doing with the filter?
For reference
For reference
Desktop looks like:,const collectSinks = (instances: Instances<WindowSinks>) => ({
DOM: instances.pickCombine(DOM).map(windows => div({ style: WindowsS }, windows)),
messages: instances.pickMerge(MESSAGES) as any as Stream<IMessage>,
state: instances.pickMerge(STATE) as any as Stream<WindowReducer>,
})
type Collection<Sources,Sinks> = (sources: Sources) => Sinks
export const Desktop: Collection<WindowSources, WindowSinks> = makeCollection<IWindow, WindowSources, WindowSinks>({
item: Window,
itemKey,
itemScope: key => '.' + key,
collectSinks,
})
Alternatively, I guess: How should I be typing the output of
makeCollection with lenses? #851 Suggests that this isn't clear in the docs.
@achou11 the PR for the new branch has an explanation: cyclejs/cyclejs#929
i.e. so the dom driver can provide the data for
sources.DOM.select().elements()
last step is implementing non-bubbling event listeners in the DOM driver
Hi there! Wondering a lot about static analysis tools (especially visualisations) for Cycle and FRP in general. @jvanbruegge @staltz Can you please give your opinion on that +- some pointers? I understand that it’s not that crucial, but to me it seems it’d help a lot for the developer. Any notable attempts in Haskell / Cycle (/Clojure?) ecosystem? I am reading through the gitter and the cycle related repos, seen @staltz’s Chrome extension, but also read that path of static analysis wasn’t preferred back then (maybe @staltz mentioned that if I recall correctly.) Please forgive me if that’s a usual topic, I’m studying Cycle a lot (and it’s history :) ), but I am so much interested in this question I can’t wait until I read everything through, 7-8 years of material is a lot! :) Digested the first half year. :)
but it is not implemented yet
I understand that the dynamic behavior can’t be statically analysed, but some extra information could be derived though for the developer (like a developer tool), at least a more approachable visual representation. I am wondering if in current, in "static time expressed -text- representation" of cycle could be just visually represented and -partially- analysed for simple but useful insights. Seen @Widdershin ’s related work (https://vimeo.com/217133774) which is a quite bit more than I am thinking of but similar in nature and seen a couple of (maybe handmade?) viz in chat like this (forgive me I can’t link the source, I have seen it back there from years ago):
As depedencies has to be explicit in Cycle, this graph can be generated, right? From plain text (assuming some extra information for parser).
(Or maybe even from ts-server?)
The easiest way to do that is not to try to statically anayze the code (as said would only work until the first flatten), but to run the app and inspect it live. With the new version if cycle, a devtool on steroids is possible, that draws such a graph at runtime including the (current version of) higher order streams and all events in general
