What was the reason of making properties in react-leaflet v3 immutable per default? Now if I change any of such a property then I must use different key to force component update. Anyway, is this the correct approach?
In v2 I found it better that properties were per default mutable and I didn't have to do such "hacks". (Property) mutability is one of the core concepts of React.
Related
I'm working on a specialized PDF reader for RPG manuals. I'm using ReSwift for state management, and I need to serialize/deserialize each window's state.
Part of a window's state might naturally consist of non-Codable objects like PDFSelections. Right now, the state instead contains Codable structs that represent the same information, and I'm converting them back and forth as needed, but this is awkward and probably not very performant. I'd like to keep the “real” objects in the state and (de)serialize them only when needed (e.g. when saving/restoring the window's state).
I'm currently using JSONEncoder/JSONDecoder for serialization. However, some of the types I would like to serialize are not Codable, and I don't see a way to provide custom logic for non-Codable types. Is there a way to make this work with JSONEncoder/JSONDecoder? If not, is there an alternative approach that might work?
I need to add a global filter to a repository entity, i.e. it has to be applied everywhere this entity is accessed on Application service layer. My filter contains two conditions. Whereas adding the first condition, which depends on a constant, is easy and applied in OnModelCreating using HasQueryFilter, I have no idea how to apply automatically the second one, which depends on the currently selected (or default) UI language.
Use dependency injection via constructor in your DbContext class. Set the currently selected UI language inside the class implementing the interface. Use the injected implementation in the OnModelCreating method to apply the filter globally with .HasQueryFilter() method like you normally would.
If you're using something like a .NET Core API, you could build a middleware that determines the language of the current incoming request. I guess the same will work for MVC too.
I created an algorithm that calculates certain things. This can be considered as the model. The algorithm is implemented in a fully functional way, so it uses immutable classes only.
Now using this model, I would like to develop a GUI layer on the top of it. However I do not know anything about the best-practises of building GUI in Scala. I intend to use ScalaFX.
My problem is the following: in ScalaFX (similarly to JavaFX) you can bind values from the GUI to object properties. This clearly violates the functional paradigm, but seems very convenient.
This would require rewriting my classes to use bindable properties which would feel like the tail wagging the dog — the model would depend on the GUI.
On the other hand, I could have an independent GUI layer. In this case I would need proxy objects to bind to and I would have to create my model objects based on these proxy objects. This would feel more idiomatic but implies a lot of code duplication and extra work. My model and the proxy objects would have to be kept in sync and I would have to take care of copying the attributes.
What is a good way of doing this? A GUI is always full of mutability so functional programming does not feel right here. Nevertheless I love Scala so I would like to keep using it for the GUI, too.
Despite the extra effort, take the second approach. Create small mutable "view" instances for each of your model. Bind the views to the widgets and install observers or hooks that update the view proxies based on changes in your model. Don't let the GUI API dictate how your concurrency approach and model should look like.
I believe there are a few open source libraries around that provide a more functional and/or reactive abstraction layer to the plain Scala-Swing or Scala-FX.
In a scala project, should entity field be mutable or immutable ?
Mutable field:
It is very easy to change field in a nested entity, also when logic is pushed into entity, it is very easy to be implemented.
Immutable field:
It guarantees consensus for one system is running, but it still may have inconsistency data if more than one systems are running, Also, if entity fields are immutable, it has lots of boilerplates to update nested fields. That means that some concept like lens should be introduced.
What should I choose to start up a scala project ?
Always favor immutability. Definitely in Scala, and probably in every other language too.
It's hard to give a more specific answer without a more specific question. But immutability is almost always a safe answer.
currently working on a GUI application using JavaFX 2 as framework. Used in Java allready and know the principles of data binding.
As the functional style programming in scala advocates the use of imutable values (vals), there is a gap.
Is there an other solution than having an mutable fx-property based presentation model for the gui and and immutable model for application logic with an conversion layer?
Greets,
Andreas
Since your question is a bit vague, please forgive if this is largely based on personal opinion: There are, to my knowledge, no other approaches to the mutable property model. I would however argue that you don't want one:
First of, functional programming, at least from a puristic point of view, attempts to avoid side effects. User interfaces, however, are exclusively about causing side effects. There is a slight philosophical mismatch to begin there.
One of the main benefits of immutable data is that you don't have to deal with control structures to avoid concurrent modification. However, JavaFX's event queue implements a very strict single-threaded approach with an implicit control of read and write access. On the other hand, user interface components fit the idea of mutable objects better than most other fields of programming. The node structure is, after all, an inherent hierarchy of stateful components.
Considering this, I think trying to force a functional and immutable paradigm on JavaFX is not going to work out. Instead, I would recommend building a translation layer based on keypath selections - e.g. binding a Label to display an (immutable) Person's name to the Person, not the name property, and having a resolver handle the access to the name attribute. Basically, this would mean having a combination of Bindings#select and a JavaBeanStringProperty.