Finish converting core to ts, JSDoc conversion, consistency+convention changes, example bugfixes #70
Conversation
…ren't needed in JSDoc
… as they aren't needed in JSDoc
junsikshim
left a comment
There was a problem hiding this comment.
Great work!
Obviously, it's impossible to review all the changed code at this stage, but I feel confident about the direction we're heading.
Also, the docs look neat :)
As Dave mentioned, we need to talk about xml components and maybe gui components. I haven't used both of them in my applications, so I can't really decide whether we actually need them nor how much we need to keep them in the same previous format(change XML to JSON?).
|
@junsikshim yep, I've merged+squashed into a single commit as don't think there's much good reason to show the million and one commits I've made :P I'm personally of the view that the GUI components can stay - I don't think they require much time to maintain, and could allow previous users of the library to more easily port applications (though maybe we should note in the docs they're mainly kept in the lib for previous apps and not recommended for new ones, as there's a lot of good UI control libs nowadays). I don't necessarily think we should remove support for XML, but currently the way the serializers work is they convert to XML first then JSON. I think this code could be easier to maintain going forwards if the lib encodes the other way around - to JSON, then convert to XML, but should look more into this before coming to a conclusion. |
|
Thanks @mcyph for this massive improvements. As @junsikshim I cannot really review everything but I am sure we are heading in the right direction. |
Summary
mx*prefixed classes, and made various class name changes for consistencyDescription for the changelog
Finish converting core to ts, JSDoc conversion, consistency+convention changes, example bugfixes
Other info
Naming/namespace changes:
mx*toMax*as e.g. Form or Window are common names and removing mx could cause clashesModel->GraphDataModelto indicate it's for the Graph and to indicate how it differs from GraphSelectionModelGraphPluginto end with*Handler(e.g.RubberBand->RubberBandHandler) to keep with this conventionutilsto different files likemathUtilsorstyleUtilsfor categorisationSerialisation still doesn't work largely because of the graph having different parameters to before and the
GraphCodecneeding to be updated, but progress has been made in allowing all other serialisers to be registered without recursive import problems by moving them into the files where they are used. It should be possible to finish the remaining issues to make it function again reasonably easily, but there needs to be some discussion around backwards compatibility and how the XML format will relate to a potential JSON format etc.More info about this branch in the comments at #64.