Known Issues

Wiki Known Issues

Thank you for making it here to the known issues page. If you would like to contribute to this project or if you're simply curious what issues this project currently has, you're in the right place.

Before making formal Github issues around the following, here is a list of what I can think of at first release of StateView.

• StateView needs tests for core functionality.
• There are properties that should be let and not var in StateView (like shadow)
• There are methods that should be private in StateView
• If you initialize and the place a UIView, and then place a StateView, the StateView and any following views can have AutoLayout constraints that directly reference the UIView. This currently doesn't work in the opposite direction. You can't place a StateView, and then use the ShadowElement that it returns to expose a UIView that could be used for AutoLayout constraints. This could possibly be done by exposing some sort of placeholder UIView in the ShadowElement that returns from the placement of a StateView so that other UIView instances can create AutoLayout constraints referencing that view, and then somewhere in Shadow.didPlaceAll resolving that constraint from the placeholder view to the initialized, or kept, StateView itself.
• Documentation is currently incomplete
• There are lifecycle methods that should be added to complement the render cycle, like viewDidUpdate(props, state) after a render is completed, viewWillUpdate(props, state) just before, etc
• Allowing for as much flexibility as there is in a dictionary with type State: Any does result in having to do a lot of if let something = props[key] as? Type. My intuition is that this is okay because this means more developers can use props and state in a way that works for them. Especially for developers coming from React and Javascript, this sort of flexibility is expected. Also, if let is safe. If there is a better way to keep this freedom but also reduce the frequency of having to unwrap values, it could improve the experience.
• Placing a UIView and then a StateView with correctly add the StateView above the UIView, but then the next render method will cause a re-add of the StateView but not below the existing StateView, and this UIView will cover that StateView. This does not happen with two StateViews because original place() order is kept.
• There is no way to force StateView to keep a UIView placed, without re-rendering it each time. Instead, you have to add the subview yourself once. Forcing a UIView to be placed is helpful when you'd like to do something like keep a background image that fades from one image to another. Maybe this can be done with some sort of placeOnce? Currently, you would have to add the subview only once in render by doing something like keeping an optional property for that view and checking for nil before adding it once in render, or using some other flag along those lines.
• Better UIView equality checking. If there was a way to compare a UILabel with another UILabel to see if they are equal key/value for key/value in their configurations, then we could spare refresh UIViews that will be exactly the same.