This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # beginners (78)
- # boot (36)
- # cider (13)
- # cljs-dev (15)
- # cljsjs (3)
- # cljsrn (10)
- # clojure (99)
- # clojure-austin (1)
- # clojure-australia (1)
- # clojure-italy (14)
- # clojure-korea (17)
- # clojure-norway (1)
- # clojure-russia (42)
- # clojure-sg (1)
- # clojure-spec (50)
- # clojure-uk (80)
- # clojurebridge (24)
- # clojurescript (83)
- # community-development (10)
- # conf-proposals (36)
- # core-async (12)
- # cursive (20)
- # datomic (38)
- # hoplon (63)
- # lambdaisland (2)
- # leiningen (6)
- # nyc (2)
- # om (54)
- # om-next (52)
- # onyx (129)
- # planck (15)
- # re-frame (38)
- # reagent (2)
- # rethinkdb (8)
- # specter (1)
- # untangled (2)
so i had an itch - building a system of objects. i don't like component, i don't like mount, yoyo & bounce have some nice ideas. i scratched it - https://github.com/employeerepublic/deferst . i think i need a better name
@mccraigmccraig I'd be interested to know your problems with each of those libraries.
mccraigmccraig had similar itch, https://github.com/reborg/scccw/blob/master/COMPONENTS.md
mccraigmccraig for people like me not into types, "deferred-state monad transformer” turns me right away, maybe put it at the bottom? Because the examples are not so mind bending after all.
Hmm, I want to add some type checking for a pet project, started reaching for Schema, and realised I should try out specs. What’s the best place to look for an overview? (slightly embarrassed that I haven’t really looked at it so far)
yeah, good idea @reborg - it's definitely not necessary to know the implementation details
@mccraigmccraig Not sure I understand what you mean by this: > unnecessary uninitialised state
Lifecycle instances have complex state - [new, start-request, started, stop-requested, stopped]... which is unnecessary - there's no reason all component initialisation can't be entirely hidden
@mccraigmccraig I've not interacted with those states, is it a pattern of some kind? All I have is my start and stop.
@dominicm right, the states implied by start/stop in a multi-threaded environment are [new, start-request, started, stop-requested, stopped]
@dominicm but the lifecycle protocol instance profusion was the principal thing i didn't like about component, rather than the unnecessary state
@mccraigmccraig I'm not fully grasping that multi-threaded condition on the component starts. I think I'm being a bit dim. Is this helpful if you're trying to start the same instance of a component multiple times in different threads? Why would you do that anyway?
@dominicm ignoring the threading (it's been a while since i used component, my memory is hazy) ... components have [new, started, stopped] states, and that's unnecessary... your component instance has to manage the transition from new to started, when really all you want to do is just create the object not create a component instance and then create the object later when that is started
but if your reduce the states to [existing] then you don't need a lifecycle anymore... just a pair of functions to create/destroy the object and you can get rid of all those useless lifecycle records
Ah, I understand the new state now. Yes, that's a bit of a fiddle,
niling out dependency fields on initialization.
@mccraigmccraig I understand your design decisions now, very intriguing. I find it interesting that you decided to marry config into the library in this way.
@dominicm i didn't set out to do that with the config - it just flowed from deciding to use the state monad (which represents a composable computation on some state), since when you run a state monad instance you start it off with some initial state - config in this case
sry for being destructive but really enjoying doing mainly aws lambdas in clj/cljs nowadays partly because i don’t even need to think about components (tried mount too, preferred it over componets)
yup, but we are experimenting to go with cljs/node.js lambdas if the function is directly linked to webUI
and not just for runtime, they reckon they can knock minutes off their build/deploy cycle too
@benedek Awesome! I'm somewhat debating over whether it's only worth using AOT for the java shim it provides.
Apparently aot does
(launch-nuclear-missiles) if it's a top-level form.
@glenjamin any specifics? i mean it should depend on how those lambdas are written, or?
sidenote if we are talking about lambdas, this is hilarious: https://github.com/microapps/recursive-lambda
we do use some
futures in some lambdas (jvm clj). they seem to be working ok. but have not done any proper benchmarking tbh
benedek how aws lambda avoid the components mumbo jumbo? Sorry I’m late on the lambda party. Any doc to get me started?
Morning. Watched a fascinating talk on Mob Programming by Woody Zuil at Agile NE. Amazing experience report wrapped up in technique talk.
doc: hm… I guess you can start reading official aws lambdas in java documentation (or node.js if you are more interested in cljs) if you want to clj specifics I would check out https://github.com/uswitch/lambada for jvm clj and https://github.com/nervous-systems/cljs-lambda for cljs
if you need to connect to some remote stateful service you might still want something componenty
the aforementioned ETL system read from kinesis and wrote to redshift - which required making a JDBC connection
@glenjamin that is true. although why would you when you can’t really keep it ‘running’ across lambda invocations?
and i think you can maintain DB connections across multiple invocations if you want to
btw in dev we just tend to run the lambda code without the lambda wrapper. so just as plain clj or cljs code. mostly from the repl anyway. and then have a
DEV qualifier on the freshest lambda version (usually qualifier is moved to that version by the build server) to test locally with
or some dev environment if not locally. so REPL driven dev is pretty easy with lambdas too
why not? specially if I can mention how to do with chaining lambdas ;) see the link above from today ;)