Hi all there is some hesitancy on my team to depend on <http kotlinlang #compose

Channels

100daysofkotlin

100daysofkotlin-2021

algolialibraries

android-architecture

android-databinding

androidgithubprojects

androidx-xprocessing

arrow-contributors

beepiz-libraries

cincinnati-user-group

codemash-precompiler

codingconventions

competitive-programming

competitivecoding

compose-android

compose-desktop

compose-ui-showcase

connect-audit-events

cscenter-course-2016

domain-driven-design

effective-kotlin

effectivekotlin

embedded-kotlin

event21-community-content

fb-internal-demo

fluid-libraries

framework-elide

getting-started

github-workflows-kt

graviton-browser

image-processing

intellij-plugins

intellij-tricks

introduce-yourself

java-to-kotlin-refactoring

jhipster-kotlin

jvm-ir-backend-feedback

k2-early-adopters

kotest-contributors

kotlin-by-example

kotlin-data-storage

kotlin-foundation

kotlin-in-action

kotlin-multiplatform-contest

kotlin-pakistan

kotlinforbeginners

kotlingforbeginners

kotlinprogrammers

kotlintest-devs

kotlinultimatechallenge

kotlinx-datetime

lambdaworld_cadiz

language-evolution

language-proposals

leedskotlinusergroup

library-development

machinelearningbawas

myndocs-oauth2-server

navigation-architecture-component

ohio-kotlin-users

pattern-matching

pocketgitclient

practical-functional-programming

prozis-android-backup

python-contributors

realworldkotlin

refactoring-to-kotlin

refreshversions

russian-kotlinasfirst

skia-wasm-interop-temp

sofl-user-group

spring-security

squarelibraries

stayhungrystayfoolish

strife-discord-lib

swagger-gradle-codegen

swiss-user-group

tricity-kotlin-user-group

Title

t

Tash

06/13/2022, 5:22 PM

Hi all, there is some hesitancy on my team to depend on https://github.com/google/accompanist given this:

Any of the features available in this group of libraries may become obsolete in the future, at which point they will (probably) become deprecated.

We will aim to provide a migration path (where possible), to whatever supersedes the functionality.

Citing that these migrations/deprecations could become problematic to maintain. Did anyone run into similar concerns and go with some alternative?

a

andrew

06/13/2022, 6:06 PM

Accompanist really is your best bet

The speed at which things get ported over to upstream compose, is not that fast

The last thing to be done was window insets, the accompanist API can still be used either way, as you migrate things over

The upgrade path for me also is pretty painless, it was pretty much just being one find and replace for most of my things

☝️🏽 1

:thank-you: 1

☝️ 1

TLDR: there really is no alternative to accompanist, it comes straight from Google developers, who either work on compose, or know people who work on compose, and it's held to the same standards that you would expect from that respective team

👍 1

☝️🏽 1

👍🏼 1

👍🏻 1

☝️🏼 1

☝️ 2

t

Tash

06/13/2022, 6:42 PM

My thoughts exactly! Thanks for confirming, Andrew 😅

c

Colton Idle

06/13/2022, 8:17 PM

Also, the best recent example of this was accompanist-inset was deprecated... but it was added to compose/android directly. And they provided a migration path to move over. 👌

:thank-you: 1

a

andrew

06/13/2022, 9:00 PM

Exactly like I said, painless

:party-parrot: 1

s

saket

06/14/2022, 1:38 AM

I also can't help but think that this line can be said for any library:

Any of the features available in this group of libraries may become obsolete in the future, at which point they will (probably) become deprecated.

😅 1

z

Zoltan Demant

06/14/2022, 3:55 AM

If you have a design system you can make adjustments in there if/when things get deprecated, instead of plowing through the projects "actual" codebase 🙂

➕ 1

t

Tash

06/15/2022, 12:37 AM

Thanks for the replies all, the team is convinced 🙌🏼

🌟 1

🙂 1

#compose Join Slack