3 ms·

Ok, so there are a lot less unintended side effects. I got that. What about the intended ones - how do You approach them? Let's say You've written a ClojureScr

by eurekin 11y ago

Ok, so there are a lot less unintended side effects. I got that. What about the intended ones - how do You approach them? Let's say You've written a ClojureScript webapp using the Angular framework and you need to migrate it to V2. AFAIK there were some breaking/conceptual changes which force significant rework. How do You make sure that after changing it everything works - even the most obscure option that only one user uses (as in the notorious example of Search Keyboard Shortcut in Outlook by Bill Gates)?

huahaiy 11y ago
One would normally use a name space to group together code that deals with a foreign library. So, upgrading to a new version of the library is just a matter of 1. update the dependencies by changing the version number of the library in project.clj; 2. load the library; 3. changing the name space (a file) that deals with the library, and 4. changing the corresponding test name space (a file), and make sure all tests pass. That's it. The Clojure coding process is REPL driven, so basically one tests every changes. Also, one codes in a bottom up fashion, starting from simple and small functions, and composing them into big functionalities. There' no big design up-front. It's an exploratory process, and it's fun.
grayrest 11y ago
> You've written a ClojureScript webapp using the Angular framework I know this is an example but Angular is terrible with Clojurescript. Clojure has an opinionated idea of how state should change over time and that opinion does not include two-way bound attributes. The reason the cljs community is virtually all React is because dom diffing makes the UI effectively a projection from state and that is epochal-time compatible. > How do You make sure that after changing it everything works - even the most obscure option that only one user uses? Depends how your app is designed. In the general case where, say, you're doing the equivalent replacing Angular with Ember you just have to do it and lean on tests/QA. I have just recently finished such a refactor and it's about as fun as you're implying. With the refactor, I have a better plan going forward! We're now on the re-frame model. All state is now in the global atom (instead of mostly being in the atom but some being component-local), dataflow is unidirectional, and we're capturing all non-determinant actions as event params. Together, it means serializing the state atom and a sequence of events allows playback on the changed code. At least in theory. I wound up having to ship rewrite delayed features and haven't taken the time to build recording/playback support.

by eurekin 11y ago

huahaiy 11y ago

One would normally use a name space to group together code that deals with a foreign library. So, upgrading to a new version of the library is just a matter of 1. update the dependencies by changing the version number of the library in project.clj; 2. load the library; 3. changing the name space (a file) that deals with the library, and 4. changing the corresponding test name space (a file), and make sure all tests pass. That's it. The Clojure coding process is REPL driven, so basically one tests every changes. Also, one codes in a bottom up fashion, starting from simple and small functions, and composing them into big functionalities. There' no big design up-front. It's an exploratory process, and it's fun.

grayrest 11y ago

> You've written a ClojureScript webapp using the Angular framework I know this is an example but Angular is terrible with Clojurescript. Clojure has an opinionated idea of how state should change over time and that opinion does not include two-way bound attributes. The reason the cljs community is virtually all React is because dom diffing makes the UI effectively a projection from state and that is epochal-time compatible. > How do You make sure that after changing it everything works - even the most obscure option that only one user uses? Depends how your app is designed. In the general case where, say, you're doing the equivalent replacing Angular with Ember you just have to do it and lean on tests/QA. I have just recently finished such a refactor and it's about as fun as you're implying. With the refactor, I have a better plan going forward! We're now on the re-frame model. All state is now in the global atom (instead of mostly being in the atom but some being component-local), dataflow is unidirectional, and we're capturing all non-determinant actions as event params. Together, it means serializing the state atom and a sequence of events allows playback on the changed code. At least in theory. I wound up having to ship rewrite delayed features and haven't taken the time to build recording/playback support.