I’ve just uploaded a SNAPSHOT version of untangled-web/om-css to clojars. The docs can be found on the develop branch here: https://github.com/untangled-web/om-css/tree/develop. This new version has a new namespace (the old API is preserved in its old namespace). The new API has a number of improvements: - Separation of localized and global rules - Better support for composition, so you don’t end up with duplication even if more than one component composes in the same subcomponent - Render no longer needs a macro expansion to “fix” css classnames. Instead a regular function can return the proper localized classnames in a map keyed by your non-localized name.
This requires the latest 1.0.0-beta1 version of Om.
Untangled is not required, but of course it is compatible.
Thanks to @timovanderkamp for working with me to design the new API. He also did most of the coding.
Hello. In the om.next and Datomic docs keywords are namespaced usually in the following style: :country/name
. Now, with clojure.spec what's the best practice here? Do you switch to a "fully" qualified namespaces like :my-app.country/name
?
My fear with fully qualified namespaces is that everything gets overly verbose. I know that I can use namespace aliases to make this bearable. Did anyone had good experience with this in the context of om.next or datomic?
@r0man with Datomic definitely there’s liberal use of aliasing
as has been said elsewhere I think it’s important to distinguish between specs for stuff that’s meant to exist outside the bounds of application and those thing that aren’t
Any growing collections of om next code bases I can study? 😃
@sova check out untangled web
it's a framework built on top of om next and there's a lot of literature associated with how to use it
it's like a less-flexible but easier-to-use version of om.next