Wartremover
Immer
Our great sponsors
Wartremover | Immer | |
---|---|---|
6 | 141 | |
1,059 | 26,943 | |
-0.3% | 1.0% | |
8.6 | 7.1 | |
12 days ago | 6 days ago | |
Scala | JavaScript | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Wartremover
-
Is Scala to Java the same relationship as TypeScript has with ECMAScript?
By contrast, Java and ECMAScript are essentially what we might call "classical" imperative OOP languages, although ECMAScript reveals much more of its Lisp-inspired "map/filter/reduce" FP roots. IMO ESLint is essentially table stakes for working with ECMAScript, but honestly, I wouldn't stop there and would insist on working in TypeScript, including some of the tooling for ESLint specifically for TypeScript, dialing type-safety up to 11, effectively like using Wart Remover with Scala.
-
Scala Resurrection
I'm awed by the maturity of the Scala 2 compiler. Every minor version in the 2.13 series adds a new linting improvement. You can see that if you have sbt-tpolecat in your project. I'm always happy to see that some option from Wartremover is no longer used.
-
New to Scala;
I was recently trying to move away from Scapegoat to Wartremover and I got bitten by this bug which is particularly prevalent in codebases using Typelevel libraries.
-
Which static analysis tool do you use for Scala?
There is also wartremover but you cannot run it separately from your compile command.
-
Newspeak and Domain Modeling
or `NonUnitStatements` without explicit annotation.
This effectively locks you into writing pure code (you can extend the linter to cover other things like not using `Future` or not using Java libs outside of `MonadError` from cats[4]). The linters operate on typed ASTs at compile time, and have plugins for the most popular scala build tools. Coupled with `-XFatalWarnings', you can guarantee that nothing unexpected happens unless you explicitly pop the escape hatch, for the most part.
You can still bring in external libraries that haven't been compiled with these safties in place, so you aren't completely safe, but if you use ZIO[5]/Typelevel[6] libraries you can be reasonably assured of referentially transparent code in practice.
There are three schools of thought, roughly, in the scala community towards the depth of using the type system and linters to provide guarantees and capabilities, currently:
1) Don't attempt to do this, it makes the barrier to entry to high for Scala juniors. I don't understand this argument - you want to allow runtime footguns you could easily prevent at compile time because the verifiable techniques take time to learn? Why did you even choose to use a typesafe language and pay the compilation time penalty that comes with it?
2) Abstract everything to the smallest possible dependency interface, including effects (code to an effect runtime, F[_] that implements the methods your code needs to run - if you handle errors, F implements MonadError, if you output do concurrent things, F implements Concurrent, etc.) and you extend the effect with your own services using tagless final or free.
3) You still use effect wrappers, but you bind the whole project always to use a concrete effect type, avoiding event abstraction, thus making it easier to code, and limiting footguns to a very particular subset (mainly threadpool providers and unsafeRun or equivalent being called eagerly in the internals of applications).
My opinion is that smallest interface with effect guarantees (#2) is best for very large, long maintenance window apps where thechoice of effect runtime might change(app), or is out of the devs' control (lib); and #3 is best for small apps.
TL/DR; You can go a really, really long way to guaranteeing effects don't run in user code in scala. Not all the way like Haskell, but far enough that it's painful to code without conforming to referential transparency.
1. https://github.com/scalacenter/scalafix
2. https://github.com/scalaz/scalazzi
3. http://www.wartremover.org/
4. https://typelevel.org/cats/api/cats/MonadError.html
5. https://zio.dev/
6. https://typelevel.org/
Immer
-
Immer VS mutative - a user suggested alternative
2 projects | 25 Jan 2024
-
Show HN: Cami.js – A No Build, Web Component Based Reactive Framework
```
It looks like it’s mutating, but both the reducers and update() uses immer* under the hood, so we still respect immutability under the hood.
Cami supports redux devtools so you can use that for time-travel debugging too!
—-
* https://github.com/immerjs/immer
- Why do we need modules at all?
-
Making Sense of React Server Components
I heard that immutability libraries like immer.js [0] help with this. Anyone go this way and had good success? Is this 'the way'?
[0]: https://immerjs.github.io/immer/
-
How We Fixed Performance With JS Object Variable Mutation
So, that's what we built, and we built it in the most obvious way — using JavaScript Proxy objects to track mutations and reflect those changes across Appsmith’s framework. Initially things looked good — it worked, aside from a few hacks to make some data types work with map and set, and we were following the example of other projects that had similar requirements. If it was good enough for them, it should be good enough for us, right?
-
The sword refers to immer, the faster and stronger immutable data js tool limu stable version released!
But is immer really the ultimate answer? The performance problem of immer is more prominent in large arrays and deep-level object scenarios. See this issue description, many authors in the community began to try to make breakthroughs, and noticed that structura and mutative, I found that it is indeed many times faster than immer as they said, but it still fails to solve the problem of both fast speed and good development experience. I will analyze the two issues in detail below.
-
Ramda: A practical functional library for JavaScript programmers
I like immer for this kind of thing: https://github.com/immerjs/immer
It gives you immutable updates without getting bogged down in FP abstractions.
-
Why my variable is being mutated if I make any changes to my data ?
I've always been a huge fan of immer for these case. For your code, it would simply turn into setGridData((prev) => produce(prev, draft => applyChanges(changes, draft)) but I recommend you go over their documentation to fully understand how it works
-
Is there a better way to do read-only types
If you're trying to make things actually immutable, Object.freeze and deep copies can clutter things up pretty good, have you considered using something like immer? (https://immerjs.github.io/immer/)
-
5 React Libraries to Level Up your Projects in 2023
If you want to set up from Context, Zustand is your best bet. It offers an extremely simple API that lets you create a store with values and functions. Then, you can access that store from anywhere in your application to read and write values. Reactivity included! If you want to store nested object data in your store, consider using Immer alongside Zustand to easily change nested state.
What are some alternatives?
Scapegoat - Scala compiler plugin for static code analysis
immutability-helper - mutate a copy of data without changing the original source
Scalastyle - scalastyle
immutable-js - Immutable persistent data collections for Javascript which increase efficiency and simplicity.
Scalafix - Refactoring and linting tool for Scala
redux-toolkit - The official, opinionated, batteries-included toolset for efficient Redux development
scalafmt - This repo is now a fork of --->
Recoil - Recoil is an experimental state management library for React apps. It provides several capabilities that are difficult to achieve with React alone, while being compatible with the newest features of React.
Linter - Static Analysis Compiler Plugin for Scala
react-query - 🤖 Powerful asynchronous state management, server-state utilities and data fetching for TS/JS, React, Solid, Svelte and Vue. [Moved to: https://github.com/TanStack/query]
Scurses - Scurses, terminal drawing API for Scala, and Onions, a Scurses framework for easy terminal UI
valtio - 💊 Valtio makes proxy-state simple for React and Vanilla