A library that assumes that the library consumer will already be providing his own version of a third party library might for instance have [org.omcljs/om "1.0.0-beta1" :scope "provided"], where the third party library is Om Next.

So what to do if there's a library that assumes that the consumer will be providing either Fulcro 2 or Om Next?

I imagine that if you do "provided" for both, then the one the consumer doesn't supply will be dragged in, even although it is not required.

Ideally there would be a directive in the lein project file to specify that any one of this set of third party libraries is enough.

@cjmurphy If it has assumed you’ll be providing one or the other, then you must provide one or the other. Why would the other be “dragged in”? Om Next isn’t any kind of dep for Fulcro 2.

not sure I understand your question

Version 1.1.0 of fulcro is on clojars. Has a couple of bug fixes, some version bumps of dependencies, custom formatters for i18n (cljs only), shadow dom (for browsers that support it), some form improvements, etc. See CHANGELOG for details.

@tony.kay: if the library is to work with one or the other it would provide both, so have [org.omcljs/om "1.0.0-beta1" :scope "provided"] and [fulcro/fulcro "2.0.0" :scope "provided"]. My assumption with "provided" is that if the consumer doesn't provide the library then the version specified is provided instead. Hence the consumer might be using Fulcro 2.0 only, yet om "1.0.0-beta1" would come in as well. But I might be wrong there.

provided means it won’t end up in your build product (e.g. uberjar) unless you actually define a version you want

e.g. Lib A says X is provided. App B requires A. If B does not specify that X is a specific dependency, then the generated jar/uberjar will not have X in it, and will not work.

So, if I want to make Fulcro SQL for example support 20 databases…I can put in integration tests and provided deps for all 20. You won’t ever get any of those. You’ll have to, say, pull in postgres driver. Now, the library has to be very careful not to accidentally refer to any of those 20 database namespaces, or it will cause the downstream consumer to fail without good reason.

Typically you use tricks to avoid referring to things that are “optional” like that

(e.g. dynamic resolution of vars)

JDBC uses DriverManager as a central registry

etc

Here’s an example where I do it with devcards: https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/cards.cljc#L101

I thought the "provided" keyword was so that App B could specify its own version of Lib C, and the version provided by Lib A would then be irrelevant. Only if App B did not specify Lib A at all would the version of Lib C provided by Lib B be used. So the version number (of Lib C) provided by Lib B acts as a default.

nope…provided basically means “put it on my classpath while I’m working on the project locally, but when someone uses me as a transitive dependency they will select a version of that that suits them. Of course, if they don’t and you really need it to be there, then it will break.

Right - so there's no defaulting, so all will work well!

So, I specify devcards in my dev dependencies….which is a little cleaner. I’m not saying the user of my lib is definitely required to provide that, then I do the actual library loading (via require) iff they really use something that needs the lib (devcard-fulcro). So the semantics of provided are different

but the functionality is that the user of the lib has to say they use it, or they don’t get it

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

I do have a library that will want to work with Fulcro and Om Next, and it can say provided for both, and there won't be any problems.

is the official definitions

technically you should probably put them both in your dev dependencies, and document how the user is meant to work with your library…because there will be “gotchas”

you don’t really want to advertise (via provided) that the lib is always going to be there…`:provided` won’t bring it in, but it does tell the consumer that they are supposed to

so, if that is not what you mean, then you make it a dev dependency so you can develop the library against both, but then you have to document that they only need to specify one…and then document how they tell you which one to use.

This is also the reason I really was very hesitant to fork off from Om Next…the APIs are going to be so similar that people will want a library that works with both 😕

well, my hope is that most ppl just use Fulcro, since it is much easier to target libraries at 🙂

In Om Next you don’t know the database format, networking system, how the server is constructed, etc, etc. Makes it kind of hard to make much that is actually reusable IMHO

Then again: If all you’re dependent on is the react generation wrappers (e.g. om.dom), it won’t hurt to have both…those are 100% compatible cross lib

The library in question understands the database format.

then how can it work with Om Next?

oh, if they choose the default one

I see

Only be used by projects that use default database format.

that’s a big if. I kind of think the only reason to consider using vanilla Om Next is if you want a custom db format…

anyway. Hope that answers your deps quesion 🙂

Yes - breaking unless the consumer requires it is a good thing.

@tony.kay what is about the shadow dom? what is been supported about that?

I just added a component that can wrap DOM in shadow dom

doesn’t work with Firefox unless you turn on a special option in the settings of the browser

but does work with Chrome and some others

ah, gotcha, I was wondering if would be something about app isolation, but makes sense know that you said, just about been able to use it, right?

More of an experimental feature that shows you how to do it…but not very generally usable yet, since the standard isn’t supported on all browsers

isolation of CSS for embedding is mainly the benefit for Fulcro

(i.e. not being affected by global resets, etc.) Fulcro-css does a nice job of keeping collisions from happening, but you still inherit

yeah, I love fulcro css by that

also, recently I learned that you can use the css: all: initial;

with that you can easily reset the entire children group, makes me question if the shadow dom will ever be useful enough to be adopted

Oh, really? That’s cool…so, you can put that in your root, and you get isolation from parent’s?

yup

unless there is some crazy rule inside, I just saw someone using it, have to test more

sweet…going to have to agree with you…shadow dom is nice in the “guaranteed isolation” sense without an iframe. So, I do hope it catches on for that purpose…but web components look like an OO disaster to me

agreed

React FTW, just works so well, and browser-drama free

FTW?

for the win*

hehe

oh, nice

bummer. docs say Safari doesn’t support initial

nor android or iOS

perhaps that is out of date

did you checked on http://caniuse.com?

@tony.kay https://caniuse.com/#feat=css-initial-value

seems like all is more of a problem, if you care about Edge: https://caniuse.com/#search=all

ah, I was looking at an outdate page

you mean IE 11?…it says edge is fine

edge is fine for initial, but not for all

the all property isn't supported there

oh, ok

yeah, I see that now

looks like it’s still iframes for most real embedded uses 😞

I guess you could do a combo…shadow dom if you detect it, and css all…that might cover the gamut

Oh no…edge is out on that too

Microsoft should just give up on browsers building, seriously....

as should Apple

at least they keep the most important features up to date

I’ve been using a mac since 2004 or something…never found Sarafi usable

I've used it for a while, but in the end Chrome is always my preferred

I was trying that new Firefox, but it doesn't have all the dev features I use, and I didn't notice that much of a speed difference as they clame (well, one thing that is noticible is that they seem to render the page before the CSS is available, I'm not sure if that is a good thing)

I wonder since initial is well-supported, if you just couldn’t generate a verbose reset that names all of the css tags

simulate all

I'm wondering if the default graph db should be extended with set #{} and map {}. By that I mean that the idents could be stored and resolved in them. Like this for sets: #{ [:entity/id 1] [:entity/id 2] } and something like this for maps { 1 [:entity/id 1], 2 [:entity/id 2] } Im wondering if there's an issue with this, or if you think it's unnecessary.

@tony.kay you probably can do something with the * selector

but I guess all works better, because it was made for it

@urbank So, not desirable, I don’t think: 1. UI’s have order. Sets don’t preserve it. So, your to-many would jumble itself 2. Not sure how you’d interpret the map version Perhaps you have more thoughts…can’t read your mind about the why so, it adds complexity to the query engine, but I’m not sure of a clear benefit. Care to enlighten me with a use-case?

Version 1.1.1 released to clojars. Has a bugfix that allows :elide-asserts true to work properly. Thanks to @gardnervickers, @wilkerlucio, and the friendly folks on the #core-async channel.