appModel.appType is unreliable

[csells]

What happened?

The Update Existing Code dialog depends on the value of appModel.appType to determine if the user is updating Dart or Flutter code. However, it appears as if the user's Flutter code hasn't been executed, the value of appModel.appType will be reported as Dart instead of Flutter. This sometimes causes the LLM to translate the user's code from Flutter to Dart during the update process.

Steps to reproduce problem

• Choose Samples | Hello World and execute the program to reset appModel.appType to Dart.
• Choose Samples | Counter and be careful NOT to execute the program.
• Choose Gemini | Update Code and the Update Existing Code dialog will think that the Flutter Counter app code is Dart and not Flutter.

Browser

Google Chrome
Version 133.0.6943.142 (Official Build) (arm64)

Are you using any extensions/plugins that affect website behavior
(particularly those that affect iframes, such as ad blockers)? No

Are there any warnings or errors in your browser's JavaScript console?
If so, paste them below:

<meta name="apple-mobile-web-app-capable" content="yes"> is deprecated. Please include <meta name="mobile-web-app-capable" content="yes">Understand this warningAI
111Chrome is moving towards a new experience that allows users to choose to browse without third-party cookies.

Machine

Operating system: macOS
Version: 15.3.1 (24D70)

Your code

What code was in the editor, if any, when the failure occurred? You
can paste it in below:

import 'package:flutter/material.dart';

void main() => runApp(const MyApp());

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      debugShowCheckedModeBanner: false,
      theme: ThemeData(colorSchemeSeed: Colors.blue),
      home: const MyHomePage(title: 'Flutter Demo Home Page'),
    );
  }
}

class MyHomePage extends StatefulWidget {
  final String title;

  const MyHomePage({super.key, required this.title});

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  int _counter = 0;

  void _incrementCounter() {
    setState(() {
      _counter++;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text(widget.title)),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            const Text('You have pushed the button this many times:'),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headlineMedium,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ),
    );
  }
}

DartPad's output

Did DartPad print anything to the console pane? If so, paste it below:

If you were running Flutter code, you can also paste an image of the
Flutter output directly into this bug report.

[johnpryan]

Have you had time to track down why it's unreliable? Is it a state-management bug?

[csells]

Yes. As stated, it relies on the code being executed to determine the type.

One work around is to auto run a new sample when it's first generated, just as generate and update code do. It won't be 100% but that should solve most cases.

I can implement this if you like.

[johnpryan]

Ideally, we could compute the app type based on the user's source code (previously I think we used to check for package:flutter/ imports). But now, we check the compiled javascript to determine if the snippet is Dart or Flutter, which is more reliable, but means that we need to compile before we can accurately set the AppModel.appType variable.

I see a couple of options:

• Go through the app and figure out all the scenarios where this could happen and invoke compilation
• Base the decision to select "Dart" or "Flutter" off of the imports in the user's code snippet (less reliable, but faster)
• Make the app type something the user can manually see and toggle in the UI

cc: @devoncarew @natebiggs

[biggs0125]

It seems like the backend server is using the imports to determine if the program is Flutter anyway:

dart-pad/pkgs/dart_services/lib/src/project_templates.dart

Line 137 in fe8178b

bool usesFlutterWeb(Iterable<ImportDirective> imports) =>

Can you clarify why doing this in the frontend is less reliable? Is it because there are indirect ways to import package:flutter from the pre-approved packages? If so we could probably enumerate those indirect dependencies and then base isFlutter on the presence of those too.

[johnpryan]

I was assuming that hasFlutterWebMarker is a more reliable way to check, otherwise we would have kept using package:flutter imports to determine this. But if it's the same either way, I think the best solution would be to just grep through the user's source and call it a day?

[csells]

Is there code on the server side that does this already? If so, we can just use the same code on the client side.

[johnpryan]

Here's the code from the previous version that checked for imports: https://github.com/dart-lang/dart-pad/blob/1499ce97b5d0d80228c4e12b8a9923e8ddcf300f/pkgs/dart_pad/lib/util/detect_flutter.dart

[csells]

If I create a new flutter snippet, the generated code doesn't have any of those. Wouldn't it make more sense to check for material, widget, cupertino or dart:UI ?

[johnpryan]

What do you mean it doesn't have flutter imports? It's checking for package:flutter, flutter_test, and dart:ui.

[csells]

I see what the code from the previous version is checking for. I’m saying that the Flutter snippet generated by DartPad doesn’t have any of those imports:

import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      debugShowCheckedModeBanner: false,
      home: Scaffold(body: Center(child: Text('Hello, World!'))),
    );
  }
}

[johnpryan]

It has package:flutter at the top, so the hasFlutterContent function would return true, right?

/// Returns whether [fileContent] appears to use Flutter.
bool hasFlutterContent(String fileContent) {
  return fileContent.contains('package:flutter/') ||
      fileContent.contains('package:flutter_test/') ||
      fileContent.contains('dart:ui') ||
      hasFirebaseContent(fileContent);
}

[biggs0125]

I’m saying that the Flutter snippet generated by DartPad doesn’t have any of those imports:

That code contains package:flutter/material which should get detected by contains('package:flutter/'.

usesFlutterWeb is doing the exact same kind of check on the imports that the old version was doing but it's including more libraries.

I checked and it's only checking imports in the user's source code. So we should be able to parse the sources in the client the same way. As Chris suggested we should just be able to move all that parsing logic into a shared location (probably dartpad_shared) and invoke it from both the client and server.

The one caveat here is that the server is using parsing logic from the analyzer. I wonder what effect including the analyzer package into the client code would have. It might bloat the app size a bit, it depends on how the tree-shaking works out. It might be fine but it's worth looking checking.

[biggs0125]

I put together this commit which moves that logic to dartpad_shared: 4aed2ae

But I also confirmed that doing this increases the size of the generated JS and WASM (for dartpad_ui) by ~15%. Before is 2,869,861 bytes. After is 3,345,688 bytes. This is likely because the entire analyzer AST is being included by the parsing logic.

[biggs0125]

The fix for this would be to implement some simpler logic to parse the source code and extract out the imported package names. This is where the code would get a bit more unreliable.... but I think we could probably come up with something reasonable.