Releases: yznts/kyoto
1.0.2
1.0.1
1.0.0
A first major release of kyoto, v1.0.0.
We went through a huge architecture changes multiple times and took some hard decisions in development process. Please note, it’s a breaking release. It’s not similar to anything published in 0.x versions.
Key concept of the new architecture comparing to struct based components - asynchronous functions as a component, based on generics and zen.Future
. As far as overall concept is not documented yet, I’d recommend checking code sources for now. It’s well documented and structured.
There is no sense to provide a change list because everything was changed drastically, so I’d like to recommend checking our documentation on https://pkg.go.dev/github.com/kyoto-framework/kyoto.
As a part of our optimizations, we are moving our documentation directly into the code. Documentation will be automatically generated by pkg.go.dev
, which would significantly ease the overall development process.
I have to apologize for drastically changing architecture right before 1.0.
This decision should have been made before the release because stable version imposes many restrictions on such movements. Sticking with not-so-good approach for compatibility with 0.x (which did not promise to stay stable anyway) is quite a bad idea.
Work on minor libraries refactor, like uikit, will start right from this moment.
If you find yourself in a bad situation because of these changes, please, let me know. I can help with adapting to this change, as our team will be doing the same. You can find contacts right in the README.
0.3.2
0.3.1
0.3.0
0.2.0
I am pleased to present a second release of this library!
We are moving slowly, but every step is quite important. It proves this "concept" is no longer just a concept. Let's take a closer look at the changes this release brings!
Features
- Multi-stage UI update on action (related issue #62). Awesome feature, proposed by @bketelsen that allows to push multiple UI updates during single action call. Useful thing to show current status/step of a long-running action. Documentation.
ssa:oncall.display
control attribute (related issue #56). Changes display parameter during action call, at the end of an action the layout will be restored. Documentationssa:onload
trigger attribute (related issue #63). Provides a way to trigger an action on page load. This may be useful for components' lazy loading. Documentationssa:poll
+ssa:poll.interval
trigger attributes (related issue #18). Provides a way to trigger an action periodically. Useful for components that have to be updated over time (f.e. charts, stats, etc.). Documentationssa:onintersect
trigger attribute (related issue #36). Provides a way to trigger an action on element intersection. Documentationssa:render.mode
control attribute (related issue #70). Determines which mode to use for dynamic DOM updating. Currently, 2 modes are supported: "morphdom" and "replace". Documentationssa.morph.ignore
andssa.morph.ignore.this
control attributes (related issue ##43). Ignore elements morphing (with or without children). Documentation is not ready yet- The possibility of using custom render method (related issue #42). It's an important step to eliminate obligatory using of
html/template
and give more control to developers. Documentation - Support ndjson (newline delimited json) output format for Insights feature (related issue #49). Documentation is not ready yet.
- Option for changing SSA endpoint (related issue #84). Documentation is not ready yet.
- Option for changing async error behavior (related issue #77). Documentation is not ready yet
Deprecated
Nothing in this release :)
But old deprecated functions from 0.1 are cleaned up.
Future plans
- Video tutorials and articles. It's not enough to have a documentation as far as it's not providing step-by-step usage guide, also some people better understand information with audio/video content.
- More attention to minor things, like UI Kit and starter project.
- Refactor rendering lifecycle architecture (related issue #93). Lifecycle is pretty similar to pipeline, so job execution system (https://github.com/kyoto-framework/scheduler) perfectly fits for this purpose.
- Functional way to define pages and components (related issue #94).
- Server side state (related issue #28).
- Support tinygo compiler (related issue #80). An important step on the road to Edge Workers.
- Cover project with tests (related issue #53).
Final words
I would like to mention and say thanks to this people:
- @RowdyHcs for active participation in project development
- @bketelsen for providing
ssa:poll
pull request, minor improvements and idea of multi-stage UI update - @OpenSauce for detailed documentation review for grammar mistakes
- @inthepanchine for ndjson insights output
- ... and other people can be found here