I'm evolving my way towards a suitable design for state with reagent given my project, and while still using distinct atoms (i'll probably switch to a single atom, but trying to explore the space of possibilities at present), I've tried to set up all state in the lexical context of the root component, as illustrated below. Idea is that this app-state is an ordinary clojure map where the value of each key is a reagent atom.
It receives an attrs map which is a prop (coming from data- attrs on the html element), and its job is to initialise an app-state map, which is not itself an r/atom, but contains r/atoms. The problem is, all of these r/atoms were defined with defonce when declared at the top of the file, which is what I've just switched from, and now the defonce semantics is lost & figwheel hot reloading is broken.
Is there a way to preserve reloadable code while setting up state in this style?
I cannot put a defonce inside a let, because subsequent times that is evaluated it will evaluate to nil.
Or is there some pattern I'm missing here.
(defn a-root-component [attrs]
(let [app-state {:some-state (r/atom (:some-state attrs))}]
(fn [attrs]
[some-component app-state])))
Technically you could use memoize, but I wouldn't. By using memoize your introducing hidden global state, cleverly hidden where no one will think to look for it. Better to defonce your state outside your main component and be explicit about it.
Given the direction your moving I'd look carefully at things like re-frame and Keemcha which provide established patterns and tooling for working with centralized state in a sane way.
Related
I am trying to come up with an efficient way to organize clickable menus for the objects in my game. I made a Menu class, from which all possible menus inherit:
class_name Menu extends Control
#contains functions (for buttons) that all menus have in common
func open_menu():
pass
func close_menu():
pass
To make a menu specific to buildings, I inherit all functionalities from the Menu class:
class_name BuildingMenu extends Menu
# contains functions specific to all buildings
func upgrade_building():
pass
func delete_building():
pass
# ... many more ...
Now here's the problem: My HQ is literally just another building with a few extras and the main difference that it can't be deleted, so I'm thinking of inheriting from BuildingMenu. Is there a way to disable the inherited delete_building() function in the HQMenu script?
class_name HQMenu extends BuildingMenu
func delete_building():
# overwriting inherited function like this does not work...
# ... some HQ specific stuff here ...
I could just inherit from Menu and then copy paste everything from BuildingMenu except the delete_building() method, but this seems somewhat clumsy because now I have to edit two files if I want to change/add any building functions.
What is the correct way to do this?
SOLUTION:
Thanks to the suggestion by Thearot I've decided to move the delete_building() function into a new class from which all the regular (non HQ) buildings inherit:
Now here's the problem: My HQ is literally just another building with a few extras and the main difference that it can't be deleted, so I'm thinking of inheriting from BuildingMenu. Is there a way to disable the inherited delete_building() function in the HQMenu script?
This sounds like a violation of Liskov Substitution Principle. From a purely object oriented point of view, it would be preferible to make another class for a subset of buildings with what they have in common, than to have one building inherit from another if it has to disable some methods.
If your base class for all buildings implies that some buildings have to disable some methods, then it does not really have the methods common for all building, it has some extra ones.
To be clear, here I'm suggesting to add another extra intermediary class, and that way you don't have to delete nor duplicate methods.
If that is not an option for you… Congratulations! you have made a mess system complex enough that some kind of component based system begins to make sense. But don't jump the line, don't fret, it is OK.
If I understand correctly you have some contextual menus that show different options depending on what is selected or what you click on, right?
That means that the options are variable. Thus, use a variable. Add an Array field that has the names of the methods that should be linked to the menu. Then have the menu system discover the options by reading that Array, and connecting to functions with the names specified there.
And how you do add or remove options? You add them or remove them form the Array. Simple. You can populate the Array in _init.
To be clear, you can check if an object has a method with has_method. You call a method by name with call, or - of course - you could connect signals to them with connect (if prefer to populate an static menu for the object instead of having a dynamic one). Yes, I'm suggesting late binding.
So, I am building a map using angular and leaflet. One of the things that I use is leaflet.markercluster. When i click on the cluster I want the popup content of a random marker of a cluster to be written somewhere. To access the popup content of some random cluster I did this:
cluster.getAllChildMarkers()[0]._popup._content
and got an error: Property '_popup' does not exist on type 'Marker'.
But the thing is, if I do ng serve first time it failes to compile, but if I change anything and save all it compiles sucessfully with the errors and I can see the content of the popup.
Also, if I do console.log(cluster.getAllChildMarkers()[0]) and I inspect element on webpage I get the regular console log of a marker with latlng andall other atributtes, including _popup.
Does anybody know why does typescript/vscode log an error, but html console sees it normally?
Because TypeScript is more strict than JavaScript, it warns you of potential issues that may actually work just fine once transpiled in JS.
In this specific case, this is simply due to the pseudo private properties ("_popup" follows the usual JS libraries convention of using an underscore _ prefix to denote pseudo private members) not being declared on the TS types of Leaflet, since you are not expected to use them.
But of course this is still technically valid in JS, so you can tell the TS compiler "I know what I am doing" by using the //#ts-ignore comment directive just above that line.
Or longer but much better, since you can remain under TS watch: use actual Leaflet API to achieve what you are doing:
getPopup() method
getContent() method
cluster.getAllChildMarkers()[0].getPopup()?.getContent()
Is there a way to execute a method exactly after the component has its properties available but before the first render?
I mean something between the class contructor() and firstUpdated().
It sounds trivial, maybe in fact I'm missing something trivial..
The element's constructor is called when the element is created, either through the HTML parser, or for example through document.createElement
The next callback is connectedCallback which is called when the DOM node is connected to the document. At this point, you have access to the element's light DOM. Make sure to call super.connectedCallback() before doing your own work, as the LitElement instance has some work to do here.
The next callback is shouldUpdate, which is an optional predicate that informs whether or not LitElement should run its render cycle. Useful if for example, you have a single observed data property and destructure deep properties of it in render. I've found that it's best to treat this one as a predicate, and not to add all sorts of lifecycle logic inside.
After that, update and render are called, then updated and firstUpdated. It's generally considered bad practice to perform side effects in render, and the occasions that you really need to override update are rare.
In your case, it sounds very much like you should do your work in connectedCallback, unless you are relying on LitElement's rendered shadow DOM, in which case, you might consider running your code in firstUpdated, then calling this.requestUpdate() to force a second update (or changing some observed property in firstUpdated)
More info: https://lit-element.polymer-project.org/guide/lifecycle
What invalidateProperties(), invalidateSize() and invalidateDisplayList() methods are did when extending a component in adobe flex/air ?.
And why these are necessary?
As per the documentation, these functions signal flex/flash to call another function before updating and rendering the display list. This "other function" seems to be for validation (and possibly altering the values if they're incorrect). So by calling an invalidate function, you force a recalculation. Or, in other words, a redraw. This removes any left over graphical artifacts.
That's my explanation via the documentation. Perhaps someone with more experience can build upon my answer.
All these components are based upon the RENDER event so no matter how many changes they go through (ex: x, y, width, etc ...) they are drawn only once per frame. But to get the RENDER event to trigger for each component a stage.invalidate() must be called and parsed on a per component basis. All the component invalidate methods allow you to force a redrawing of the component by skying the RENDER event step or in other cases by starting the RENDER event workflow.
Suppose I have a setting in NSuserdefaults that should affect a property for a lot (but not all) UIView objects, for example the font size.
The setting can also be changed from a 'main' viewcontroller and should be 'distributed' to UILabel objects that live in a UIView in a UITableviewcell inside a UITableView inside a UINavigationController inside a UISplitviewController and so on...
If I create this property on all levels of the controller and view hierarchy, and set the property when the property in the parent is set, this costs a lot of code.
Apple seems to prefer this pattern to manage the managedObjectContext by handing it to the child controller along the chain.
But this seems like overkill. Lot of code is just for passing around the value of the property, while nothing is done with it. I do however use this pattern to set properties in all subviews of a view at once (by recursively walking through all subviews).
Delegation seems to be just as bad, except maybe not if the delegate would be top level parent view controller. But then I would be passing the delegate around to all child view controllers.
Should I go with Notifications instead? I already have a controller listening to (all) changes in the NSUserDefaults via the NSUserDefaultsDidChangeNotification. Should that controller post a specific notification when my setting is changed? In that case, who should listen to it? Should it be the view controller that is responsible for the views involved?
After some more reading, I found advise in the book Cocoa Design Patterns from Buck / Yacktman, as they state:
As a general rule, use notifications when there are potentially many objects that may observe the notification. Use delegates when exactly one object is given an opportunity to influence or react to changes as they are happening.
So notifications is the answer.